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ABSTRACT 


The  area  of  concern  addressed  by  this  thesis  is  the  development  of  a  3-D  visual 
simulation  to  aid  in  the  testing  of  ground  detection  and  foot  placement  algorithms  for  an 
articulated  walking  robot’s  foot  pads  on  uneven  terrain. 

Several  collision  detection  algorithms  and  terrain  mapping  techniques  were  studied  to 
determine  which  approach  would  lend  itself  readily  to  the  rapid  detection  of  initial  ground 
contact  and  the  required  orientation  needed  to  place  each  foot  firmly  on  the  ground. 

As  a  result  of  these  studies,  a  real-time,  realistic  and  aesthetically  pleasing  graphical 
simulation  for  the  testing  of  control  software  for  articulated  walking  machines  has  been 
developed  which  utilizes  the  Silicon  Graphics  3-D  visual  simulation  toolkit.  Performer. 
Not  only  is  rapid  ground  contact  sensing  and  foot  orientation  possible,  it  is  accomplished 
without  using  extraneous  data  structures  making  the  algorithm  generic  enough  to  use  on 
any  terrain  model. 
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L  INTRODUCTION 


A.  AQUAROBOT 

Aquarobot  (Figure  1)  is  a  6  legged  articulated  walking  robot  developed  by  the  Port  and 
Harbour  Research  Institute  of  Japan  (PHRI),  for  the  purpose  of  surveying  the  construction 
of  an  undersea  rock  mound  seawall  foundation.  This  seawall  is  being  built  to  protect 


Figure  1:  Aquarobot  Being  Lowered  into  Yokosuka  Bay 


portions  of  Japan’s  coastline  from  tidal  waves  (tsunamis),  which  have  inflicted  severe 
damage  and  loss  of  life  in  the  past  The  primary  functions  of  Aquarobot  are  to;  1)  measure 
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the  flatness  of  the  rock  mound  which  will  support  a  caisson  barrier,  and  2)  survey  the 
placement  of  the  cement  caissons  utilizing  its  on-board  camera. 

After  completing  several  successful  inspections,  it  was  determined  that  human  divers 
could  perform  the  surveys  more  cost  effectively  than  Aquarobot  due  to  the  number  of 
people  needed  to  lower,  control,  and  recover  Aquarobot  using  the  current  vehicle  software 
and  “man  in  the  loop”  operational  concept  [Ref.  1]. 

B.  NFS  INVOLVEMENT 

The  Naval  Postgraduate  School,  under  a  grant  from  the  National  Science  Foundation 
(NSF),  is  developing  gait  algorithms  to  increase  the  speed  and  improve  the  efficiency  the 
Aquarobot.  A  long  range  goal  of  this  project  is  to  achieve  fiilly  autonomous  operation  of 
Aquarobot  and  similar  vehicles  [Ref.  2, 3]. 


Figure  2:  Graphical  Model  of  the  Aquarobot  in  a  Simulated 
Underwater  Environment 
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To  ensure  that  new  software  is  performing  correctly  prior  to  actual  use.  a  graphical 
simulation  is  being  developed  to  test  aU  foreseeable  situations.  Once  the  software  has 
performed  adequately  in  a  controlled  graphical  environment,  then  it  will  be  tested  on  the 
actual  Aquarobot. 

Figure  2  depicts  the  latest  3D  model  of  Aquarobot  in  a  simulated  underwater 
environment.  Even  though  this  is  the  correct  environment  for  the  robot,  the  simulated 
murky  water  makes  the  robot  more  difficult  to  see  and  slows  down  the  simulation.  For  these 
reasons,  the  simulation  results  shown  in  the  remainder  of  this  thesis  have  the  appearance  of 
being  performed  on  dry  land,  when  in  actuality  the  robot  behaves  as  if  it  were  in  an 
underwater  environment 

C.  SUMMARY  OF  CHAPTERS 

Chapter  n  is  a  brief  history  of  the  advances  computer  simulation  has  taken  in  becoming 
a  tool  for  project  development  Also  included  is  a  look  at  where  walking  robots  stand  today 
and  a  survey  of  work  accomplished  by  individuals  previously  involved  with  the  Aquarobot 
project  at  the  Naval  Postgraduate  School.  Chapter  HI  discuses  the  software  tool  Performer 
which  is  used  to  enhance  the  graphical  simulation  and  provides  a  description  of  the 
graphical  model.  Chapter  IV  describes  environment  modeling  and  terrain  identification. 
Chapter  V  deals  with  the  algorithms  used  to  detect  foot  contact  with  the  ground  and  with 
the  orientation  of  Aquarobot’ s  foot  pads  to  conform  to  uneven  terrain.  Chapter  VI  is  a 
complete  description  of  the  simulation  and  its  use.  Chapter  Vn  presents  the  conclusions  of 
this  research  and  recommendations  for  follow  on  work.  Appendices  A  and  B  contain 
program  code.  Appendix  C  provides  a  description  of  a  NPSGDL  to  Performer  loader. 
Source  code  for  this  loader  can  be  obtained  by  contacting  the  author. 
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IL  SURVEY  OF  PREVIOUS  WORK 

A.  WALKING  MACHINES 

Researchers  began  seriously  investigating  the  use  of  terrain-adaptive  vehicles  around 
1970  for  the  purposes  of  off -road  transportation,  space  assembly  and  forestry  [Ref.  4] 

The  majority  of  walking  machines  today  are  research  prototypes  limited  to  navigating 
smooth,  non-compliant  surfaces.  [Ref.  5]  discusses  the  first  legged  vehicle  model  to 
Incorporate  foot  slippage  and  sinkage  and  foot  placement  on  rocks,  uneven  surfaces  and 
slopes. 

Aquarobot  is  the  first  walking  machine  constructed  for  a  specific  purpose,  the 
inspection  of  an  undersea  rock  wall  foundation  off  Japan’s  coastline  [Ref.  6]. 

B.  GRAPHICAL  SIMULATION 

Using  computer  simulations  to  aid  in  the  testing  of  products  is  by  no  means  emerging 
technology.  But  the  idea  of  creating  a  virtual  environment  for  the  testing  of  a  product  before 
the  product  is  even  built  is  relatively  new  [Ref.  7]. 

C.  PRIOR  CONTRIBUTIONS  TO  THE  AQUAROBOT  PROJECT 

The  Naval  Postgraduate  school  first  got  involved  in  the  Aquarobot  project  in  1992. 
Since  then  it  has  been  the  subject  of  four  masters  theses  (including  this  one),  one  Ph.D 
dissertation  and  numerous  papers.  Current  research  is  divided  into  two  distinct  categories, 
control  software  and  simulation. 

1.  Control  Software 

New  control  software  is  being  developed  which  will  increase  the  speed  and 
efficiency  of  Aquarobot‘s  motion  (gait).  The  gait  currently  used  is  a  discrete  tripod  gait. 
Three  legs  are  moved  in  a  group  and  the  torso  only  moves  when  all  six  feet  are  on  the 
ground.  The  new  gait  algorithm  (wave  gait)  allows  for  the  control  of  individual  legs  to 
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maintain  a  “smooth  and  dynamic  trajectory”  of  the  torso  [Ref.  8],  and  takes  optimal 
advantage  of  the  range  of  motion  for  the  legs  while  maintaining  a  sufficient  margin  for 
stability  [Ref.  1]. 

2.  Simulation 

[Ref.  9]  establishes  a  kinematics  model  based  on  the  Modified  Danevit- 
Hartcnberg  (Craig)  method  of  representing  articulated  joints.  This  model  was  then  used  in 
the  development  of  the  simplified  dynamic  simulation  which  models  the  DC  motors  that 
control  the  motion  of  the  joints  [Ref.  10].  A  complete  hydrodynamics  model  is  being 
developed  [Ref.  1 1]  which  will  provide  the  base  line  data  to  verify  the  dynamic  simulation. 
This  is  necessary  since  it  is  unluckily  that  the  hydrodynamic  simulation  will  run  in  real¬ 
time. 

The  work  presented  in  this  thesis  develops  a  3D  simulation  to  display  the  results 
of  the  dynamic  simulation.  It  also  deals  with  the  issue  of  detecting  foot  collisions  with  the 
ground  and  foot  pad  orientation  on  uneven  torain. 
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III.  GRAPHICAL  SIMULATION  USING  PERFORMER 


IRIS  Performer  is  a  3D  software  toolkit  developed  by  Silicon  Graphics  Inc.  (SGI)  for 
developing  real-time  visual  simulations  on  their  graphics  systems.  Performer  combines  an 
application  programming  interface  (API)  with  a  high-performance  rendering  library  to  take 
full  advantage  of  the  advanced  hardware  improvements  of  SGI’s  Reality  Engine  visual 
simulation  system[Ref.  12]. 

There  is  no  provision  for  off-line  storage  of  this  visual  database,  so  a  conversion 
program  must  be  used  to  create  the  run-time  structure  from  some  other  database  format 
The  current  implementation  of  the  Aquarobot  Simulator  uses  a  locally  developed  visual 
database  called  NPS  Graphical  Description  Language  (NPSGDL2)  to  describe  the 
articulated  pieces  which  the  robot  is  comprised  of.  A  loader  then  reads  the  NPSGDL2 
descriptions,  converts  them  to  Performer  format  and  stores  them  in  memory  for  later 
rendering.  The  NPSGDL2  loader  is  discussed  in  detail  in  Appendix  C.  The  graphical  model 
is  further  discussed  in  Section  D. 

A.  HIERARCHICAL  DATABASE  STRUCTURE 

Performer  uses  a  spatially  organized  hierarchical  database  structure  that  is  created  at 
run-time  for  scene  management  A  hierarchical  visual  database  is  a  tree-like  structure 
which  contains  aU  of  the  transformations  and  geometry  needed  to  render  a  3D  graphics 
image.  A  node  may  have  more  than  one  parent  which  prevents  the  database  from  being  a 
true  tree.  Figure  3  describes  a  simplistic  Performer  database. 

1.  pfScene^ 

A  pfScene  is  the  root  node  of  the  visual  database  It  functions  in  the  same  manner 
as  a  pfGroup  with  the  exception  that  it  can  not  be  a  child  of  any  other  pfGroup. 

1.  All  Peifonner  types  and  functions  begin  with  ‘pf  to  indicate  it  is  a  Performer  feature. 
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^^^fGeode^ 


Figure  3:  Simple  Performer  Hierarchy 


2.  pfGroup 

A  pfGroup  is  a  branch  node  in  the  visual  database  and  can  have  any  other  type 
of  node  as  a  child  except  for  the  pfScene  node.  It  is  used  to  group  other  nodes  in  the 
database  spatially.  A  pfGroup  may  share  information  with  another  pfGroup.  This  allows 
multiple  instances  of  a  model  at  different  locations  and  orientations  while  only  having  a 
single  model  description  in  memory  at  run  dme. 

3.  pfGeode 

A  pfGeode  (Geometry  Node)  is  a  leaf  node  that  contains  the  graphics 
information  which  defines  the  visual  simulation.  A  pfGeode  is  comprised  of  pfGeoSets  and 
pfGeoStates  which  are  described  below.  A  pfGeode  may  have  more  than  one  parent. 

B.  IMPLEMENTATION 

To  have  a  better  understanding  of  the  graphical  model  of  Aquarobot  and  of  the  foot 
placement  algorithm,  it  is  beneficial  to  comprehend  a  few  of  the  types,  structures  and 
functions  that  Performer  provides.  For  a  more  complete  description  of  Performer  see  [Ref. 
12, 13]. 
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1.  pfSCS 


A  pfSCS  is  a  Static  Coordinate  System.  Position,  orientation,  and  scale 
transformations  can  be  applied  when  a  node  is  added  to  the  visual  database.  Since  this  is  a 
static  coordinate  system,  these  transformations  are  only  applied  once.  This  allows 
instancing  of  a  single  model  at  several  locations  within  the  virtual  world  or  allows  for  the 
placement  of  articulated  parts  so  that  movement  of  these  parts  can  simply  be  done  with  a 
rotation  about  the  joint  axis.  A  pfSCS  is  a  type  of  pfGroup. 

2.  pfDCS 

A  pfDCS  is  a  Dynamic  Coordinate  System  used  to  translate  and  rotate  objects  at 
run-time.  These  nodes  are  used  for  all  object  movement,  from  articulated  parts,  to  actually 
moving  objects  around  in  a  virtual  world.  A  pfDCS  is  a  type  of  pfGroun. 

3.  pfGeoSet 

A  pfGeoSet  (“Geometry  Set”)  is  a  collection  of  like  geometry^.  The  elements 
within  a  pfGeoSet  are  called  primitives  and  may  be  any  one  of  points,  lines,  linestrips,  tris 

(3  sided  polygons),  quads  (4  sided  polygons),  or  tristrips^.  Primitives  are  described  using 
votex  lists  which  may  be  indexed  or  not  indexed  depending  on  whether  or  not  memory 
needs  to  be  conserved. 

4.  pfGeoState 

A  pfGeoState  describes  the  graphics  state  for  the  pfGeoSet  for  which  it  is  applied 
to.  The  state  describes  such  features  as  material,  textures,  texture  environment  and 
transparency. 


2.  Like  geometry  refers  to  a  collection  of  primitives  which  are  of  the  same  type,  and  have  the  same 
state  information. 

3.  A  tristrip  is  a  collection  of  three  sided  polygons  q)ecified  by  a  sequence  of  the  three  most  recent 
vertices. 
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5.  pfSeg 

A  pfSeg  is  a  non-graphical  line  segment  described  by  a  starting  position,  a 
direction  and  a  length.  These  line  segments,  or  intersecting  rays,  are  used  for  intersection 
testing  with  the  stored  geometry. 

6.  pfisect 

A  pfisect  is  a  structure  which  contains  information  about  the  geometry  that  a 
pfSeg  intersects  with.  The  structure  definition  is  included  at  this  time  for  completeness.  A 
more  thorough  discussion  will  be  given  on  the  data  actually  used  in  Chapter  IV. 
typedef  struct  { 

long  flags;  /*  intersection  and  structure  validity  */ 

long  segnum;  /’"  the  number  of  the  segment  that  has  intersected*/ 

pfSeg  seg;  t*  description  of  segment  that  has  intersected  */ 

pfVec3^  point;  /*  point  of  intersection  */ 
pfVec3  norm;  /*  normal  at  intersection  point  */ 
long  tri;  /*  index  of  triangle  in  the  primitive  */ 

long  prim;  /*  index  of  primitive  in  the  geoset  */ 

pfGeoSet*  gset;  /*  pfGeoSet  of  intersection  ♦/ 
void*  userdata;  /*  data  for  user  in  callback  */ 
pfMaiiix^  xform;  /*  transformation  to  word  coordinates  */ 

}  pfisect; 

7.  pfPlane 

A  pfPlane  is  a  structure  which  describes  a  non-graphical,  2-D,  infinite  plane 
which  is  used  for  intersection  testing.  A  pfPlane  is  created  using  a  point  and  a  normal: 

pfMakeNormPiPlaneipfPlane  pfVecS  norm^  pfVec3  pos) 

or  it  is  created  using  three  points  which  will  derine  any  plane; 

4.  A  pfVbc3  is  an  anay  3  floats 

5.  A  pfMatrix  is  a  4X4  array  of  floats. 
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pfMakePtsPlane  (pfPlane  *dst,  pfVeeS  ptl,  pfVecS  pt2,  pfVeeS  pt3) 


8.  pfCylinder 

A  pfCylinder  is  a  non-graphical  cylindrical  volume  used  for  intersection  testing. 
It  is  defined  as: 

typcdef  struct  { 

pfVec3  center, 
float  radius; 
pfVec3  axis; 
float  halfLength; 

}  pfCylinder; 

A  pfCylinder  can  be  constructed  to  encompass  a  group  of  pfSegs.  This  allows 
for  a  more  rapid  intersection  detennination  since  the  pfSegs  only  intersect  the  geometry  if 
the  pfCylinder  does.  A  single  test  with  the  cylinder  can  be  performed  prior  to  testing 
individual  segments.  Figure  4  shows  a  pfCylinder  around  4  pfSegs. 


Figure  4:  A  pfCylinder  around  pfSegs 
The  pfCylinder  is  created  using: 

pfCylAroundSegs(pJCylinder  *dstf  pfSeg  **5egSf  long  nseg) 
where  nseg  is  the  number  of  segments  to  be  encompassed  by  the  cylinder.  A  maximum  of 
32  pfSegs  may  be  defined. 
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C.  COORDINATE  SYSTEM 

Performer  utilizes  an  orthogonal  coordinate  system  with  the  X  axis  out  of  the  screen, 
the  Y  axis  to  the  right  and  the  Z  axis  up.  This  differs  from  the  conventional  robotics 
coordinate  system  where  the  X  axis  is  North  (right),  the  Y  axis  is  East  (out  of  screen)  and 
the  Z  axis  is  down. 

In  order  to  ease  the  incorporation  of  the  motor  dynamics  simulation  [Ref.  10]  and  the 
hydrodynamic  simulation  [Ref.  11]  with  the  gr^hical  simulation,  it  was  necessary  to 
transform  the  graphics  coordinate  system  into  the  robotics  coordinate  system.  This  can  be 
done  in  two  ways.  The  first  is  to  manipulate  the  view  volume  [Ref.  10]  which  changes  the 
world  coordinate  system.  Doing  this,  makes  the  simulation  difficult  to  combine  with  other 
graphics  simulations  and  thus  minimizes  its  portability. 

The  second  method  is  to  isolate  the  Aquaiobot  simulation  from  the  grsqphics 
environment  This  allows  the  control  algorithms  to  perform  joint  rotations  and  center  of 
body  translations  and  rotations  using  conventional  robotics  notation  while  allowing  the 
robot  to  move  in  a  conventional  graphics  world. 

1.  Joint  Axis  Notation 

In  robotics,  there  is  also  a  set  notation  for  the  manipulation  of  articulated  links. 
The  X  axis  is  the  common  normal  from  the  inboard  joint  axis  (closest  to  center  of  body)  to 
the  outboard  joint  axis.  The  Z  axis  is  along  the  axis  of  rotation  for  the  inboard  joint  and  the 
positive  direction  is  chosen  to  be  which  ever  is  beneficial  to  the  implementor.  The  Y  axis 
is  orthogonal  to  the  X  and  Z  axes  using  the  conventional  right  hand  notation  (Figure  S). 


Figure  5:  Robotics  Jmnt  Axis  Notation 
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D.  Afil^iliiOBOrCONSTRUCnON 

Aquarobot  consists  of  a  cylindrical  torso,  six  articulated  legs,  an  articulated  camera 
boom,  and  a  100  meter  tether  cable  which  connects  the  robot  to  a  support  vessel  (not 
shown).  Each  leg  consists  of  four  links,  a  shoulder,  an  upper  leg,  a  lower  leg,  and  a  foot 
pad.  The  camera  boom  consists  two  links  attached  to  a  rotating  base  at  the  top  of  the  torso 
(Hgure  6). 


Figure  6:  Graphical  Representation  oK  Aquarobot 

The  Aquarobot  model  was  constructed  by  hand  using  technical  drawings  and 
photographs  as  a  guide.  Each  articulated  piece  was  broken  down  into  a  set  of  polygons  and 
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then  stored  in  a  visual  database,  NPSGDL.  Performer  was  then  used  to  detine  an  articulated 
system  in  which  to  display  the  models. 


1. 


Performer  Node  Structure 

Depicted  in  Figure  7,  is  the  tree  structure  for  the  torso  and  one  articulated  leg  of 


Figure  7:  Performer  Node  Structure  for  Aquarobot 


Aquarobot.  The  tree  is  comprised  of  static  coordinate  systems  (pfSCS),  dynamic 
coordinate  systems  (pfDCS)  and  pfGeodes,  which  contain  the  models  for  each  of  the  five 


different  articulated  pieces.^  The  numbers  adjacent  to  arcs  indicate  the  number  of  branches 
being  represented.  All  nodes  on  a  branch  are  duplicated  the  indicated  number  of  times 
except  for  the  pfGeodes.  Models  need  only  be  stored  once  and  may  be  referenced  many 
times. 

a.  Articulations 

When  constructing  articulated  links,  the  pfSCS  is  necessary  to  translate 
and/or  rotate  the  local  coordinate  system  from  joint  to  joint  in  order  to  achieve  a  coordinate 
system  at  the  next  joint  in  succession  that  is  oriented  with  the  Z  axis  coincident  with  the 
axis  of  rotation  (Figure  8).  The  pfDCS  is  then  used  to  perform  a  single  Z  axis  rotation  which 


Figure  8:  Coordinate  Systems  for  Ibrso  and  a  I^pical  Leg  With  Foot  Pad 


6.  Ihe  camera  boom  was  omitted  fcx  simplicity 


will  place  the  leg  in  the  desired  orientation.  Figure  9  shows  the  orientation  of  the  local 
coordinate  systems  after  being  rotated. 
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Figure  9:  Local  Coordinate  Systems  After  Bang  Rotated 

b.  Torso  Local  Coordinate  System 

The  top  pfSCS  establishes  the  correct  orientation  for  the  torso’s  local 
coordinate  system.  It  is  achieved  by  performing  two  successive  rotations;  a  90  degree 
rotation  about  the  Z  axis  and  a  180  degree  rotation  about  the  Y  axis,  and  performing  a  single 
matrix  multiplication.  This  transforms  Performer’s  coordinate  system  into  a  robotics 
coordinate  system.  The  torso  pfDCS  is  then  used  to  translate  and  rotate  Aquarobot 
throughout  the  graphics  environment 

c.  Foot  Pad  Local  Coordinate  System 

The  foot  pad  coordinate  system  is  unique  in  that  the  position  is  determined 
by  the  orientation  of  the  previous  links  and  the  orientation  is  determined  by  the  terrain 
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characteristics.  If  the  coordinate  system  was  linked  to  the  lower  leg,  all  previous  rotations 
would  need  to  be  removed  from  foot’s  pfDCS  in  order  for  the  foot  orientation  algorithm  to 
place  the  foot  correctly  (the  algorithm  assumes  a  non  rotated  coordinate  system  initially). 
So  in  order  to  maintain  an  initial  non-rotated  coordinate  system  for  the  feet,  it  was  decided 
to  attach  the  coordinate  system  to  the  world.  This  does  have  a  potential  drawback.  Since 
the  foot ‘s  position  is  based  on  the  world  coordinate  system,  the  foot  position  calculated 
from  the  gait  algorithm  must  be  transformed  to  world  coordinates.  The  simplistic  gait 
algorithm  used  in  this  research  was  originally  designed  in  world  coordinates,  so  this 
transformation  was  not  necessary. 

2.  Joint  Limits 

Each  limb  has  a  physical  joint  limit  which  prevents  the  limbs  from  bending  too 
far.  The  control  software  has  a  joint  limit  also,  which  is  used  to  try  and  prevent  the  use  of 
the  physical  stops.  To  ensure  the  new  control  software  is  performing  correctly,  physical 
stops  in  the  graphical  model  were  not  incorporated. 

a.  BaU  Joints 

The  ball  joint  has  a  physical  limit  as  well.  Unlike  the  other  joints,  when  this 
limit  is  reached,  the  foot  pad  will  begin  to  tilt  in  the  direction  the  leg  is  going  (Figure  10). 


Figure  10:  Motion  of  Foot  When  Joint  Limit  is  Reached 

This  limit  is  not  controlled  by  the  gait  algorithm  since  it  is  determined  by  both  the  foot 
orientation  on  the  ground  and  the  leg  position.  Reaching  this  limit  causes  the  foot  position 
to  change  which  tlien  needs  to  be  relayed  to  the  gait  algorithm  so  a  new  leg  position  can  be 
calculated.  This  feedback  is  beyond  the  scope  of  this  research  and  is  left  for  future  work. 


IV.  ENVIRONMENT  MODELING  FOR  FOOT  PLACEMEN  F 

The  first  Aquarobot  simulation  was  limited  to  traversing  on  flat  terrain.  The  moving 
feet  continued  to  move  until  they  reached  a  known  plane,  then  the  next  set  of  feet  would  be 
moved.  The  actual  robot  has  sensors  in  the  ball  joint  of  each  foot  to  signal  ground  contact 
When  a  foot  touches  ground,  and  is  exerting  enough  force  to  support  the  robot  the  control 
software  knows  to  stop  the  vertical  motion  of  that  foot  and  can  continue  on  with  the  gait 
pattern.  The  first  step  in  trying  to  simulate  the  functionality  of  the  foot  sensors  is  to 
establish  a  terrain  on  which  to  walk. 

A.  TERRAIN  MODEL 

There  are  many  different  types  of  terrain  throughout  the  world,  many  of  which  are  only 
traversable  by  some  sort  of  legged  creature.  Since  an  exhaustive  model  displaying  all  the 
types  of  terrain  is  difficult  to  achieve,  not  to  mention  being  beyond  the  scope  of  this  thesis, 
a  simplified  terrain  representing  certain  feanires  was  designed  to  test  the  foot  placement 
algorithm. 

1.  Characteristics 

Figure  1 1  illustrates  the  different  characteristics  portrayed  in  the  terrain  model. 
The  foot  pad  shows  the  relative  size  of  a  foot  compared  to  that  of  the  terrain.  Each  of  these 
terrain  types  have  unique  characteristics  which  must  be  overcome  by  the  foot  placement 
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Multiple  Slopes 

Figure  11:  Different  Terrain  Types  Used  in  Terrain  Model 


B.  LIMITATIONS  DUE  TO  GATT  ALGORITHM 

The  simplistic  gait  algorithm  used  while  testing  the  simulation  had  some  strict 
limitations  imposed  upon  it  since  it  was  originally  designed  for  flat  terrain.  The  vertical 
range  of  the  foot  is  0  to  20  cm,  so  the  terrain  must  be  modeled  within  this  range.  The  torso’s 
height  is  fixed.  If  the  terrain  rises,  the  upper  leg’s  joint  angle  will  increase  and  the  torso  will 
be  closer  to  the  ground. 
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C.  TERRAIN  IDENTIFICATION 


A  useful  feature  provided  by  Performer  is  the  ability  to  assign  a  unique  16  bit 
hexadecimal  identification  number  to  each  node.  This  ID,  known  as  a  traversal  mask,  is  set 
by  the  Performer  function: 

pfNodeTravMask  (pfNode  *node,  long  which,  ulong  mask, 
long  setMode,  long  biiOp) 

The  node  specifies  which  node  in  the  scene  to  begin  with  when  determining  how  to 
assign  the  traversal  mask.  The  which  value  identifies  the  traversal  type  that  the  mask  is  for. 
The  setMode  indicates  if  the  mask  is  to  be  assigned  to  the  node,  the  node’s  descendents  or 
both.  The  bitOp  is  used  to  set  the  node’s  mask,  or  change  a  pre-existing  one. 

When  a  traversal  is  executed  (either  draw,  cull,  or  intersect!,  a  bitwise  ‘AND’  is 
performed  between  the  mask  of  the  traversing  function  (Chapter  V,  Section  B),  and  the 
traversal  mask  of  the  terrain,  if  the  result  is  non-zoro,  the  traversal  is  continued  to  the  nodes 
descendents.  if  the  result  is  zero,  the  branch  is  pruned  and  the  traversal  continues  on  to  a 
sibling,  if  one  exists,  shows  the  results  of  distinguishing  between  different  terrain  types. 


Figure  12:  Aquarobot  Standing  in  Water 
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D.  UNDERWATER  ENVIRONMENT 

The  undersea  environment  in  which  Aquarobot  operates  in  can  be  simulated 
using  Performer’s  environment  effects  function  for  fog.  Though  this  gives  a  fairly  accurate 
impression  of  being  underwater,  this  effect  is  only  used  for  demonstration  purposes.  TTie 
fogging  effect  places  a  serious  drain  on  the  hardware  and  slows  the  simulation 

E.  RESULTS 

The  limitations  on  the  terrain  traversed  in  the  simulation  has  no  bearing  on  the 
functionality  of  the  foot  placement  algorithm  to  follow.  Terrain  limitations  are  a  result  of 
limiutions  imposed  on  the  gait  algorithm.  The  foot  placement  algorithm  is  generic  in 
nature  to  work  with  any  gait  pattern. 


20 


V.  GROUND  CONTACT  DETERMINATION 


Performer  has  two  features  which  significantly  enhance  the  ability  to  determine  when 
two  graphical  objects  come  in  contact  with  each  other.  These  are  bounding  volumes  and 
intersecting  rays. 

A.  BOUNDING  VOLUMES 

A  bounding  volume  is  an  imaginary  space  which  encompasses  an  object  (Figure  13). 


Figure  13:  Bounding  Box  for  an  Upper  Leg 


Performer  has  five  different  types  of  bounding  volumes,  these  are  boxes,  spheres, 
fiustrums,  half  space,  defined  by  a  pfPlane  (Ch^ter  m.  Section  B),  and  cylinders. 

When  an  intersection  test  is  performed  between  two  bounding  volumes,  the  results  are; 

•  No  intersection 

•  Partial  intersection 

•  Complete  intersection:  One  volume  completely  inside  the  other 

These  limited  responses  do  not  allow  for  the  positioning  of  one  volume  against  another,  so 

volumes  are  inadequate  for  the  orientation  of  the  foot  pads  on  uneven  terrain. 
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Another  drawback  to  using  bounding  volumes  is  that  they  must  be  axially  aligned.  If 
the  object’s  coordinate  system  is  not  coincident  with^e  world  coordinate  system,  the 
bounding  volume  does  not  give  a  true  representation  of  the  bounded  object 


Figure  14:  Growth  of  a  Bounding  Volume 


Figure  14  illustrates  the  expansion  of  a  bounding  volume  when  the  object  it 
encompasses  is  rotated  45  degrees.  Since  the  bounding  volume  grew  from  one  square  inch 
to  two  square  inches,  half  of  the  intersections  widt  this  object  will  be  false  (solid  grey  area 
represent  false  collisions).  These  are  unacceptable  results  in  a  visual  simulation. 

B.  INTERSECTING  SEGMENTS 

As  previously  mentioned,  Perfomwr  utilizes  pfSegs,  non-graphical  line  segments,  to 
test  the  scene  geometry  during  the  intersection  traversal  of  the  node  structure.  These 
segments  are  projected  from  a  desired  position  for  a  given  direction  and  distance. 
Intersection  testing  is  accomplished  using  the  Performer  command: 

pfSegsIsectNodeipfNode  *node,  pfSeg  **segs,  long  nseg,  long  mode, 
ulong  mask,  pfCylinder  *bcyl,  pfisect  *isects, 
long  (*discFunc)(pfIsect  *isect)) 

The  traversal  begins  at  the  specified  pfNode,  and  all  descendents  are  checked  for 
intersection  with  the  nseg  number  of  pfSegs.  Performer  allows  up  to  32  pfSegs  to  be 
specified  for  any  intersection  routine.  To  reduce  traversal  times,  a  pfCylinder  is  specified 
which  encompasses  the  pfSegs  (see  Chapt^  m.  Section  B). 
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For  each  pfSeg  which  successfully  intersects  the  geometry,  the  intersection  traversal 
returns  information  which  is  stored  in  an  array  of  nseg  pfisect  structures  (see  Chapter  m. 
Section  B).  The  only  information  currently  being  used  is  the  terrain  height  (Z  position  in 
local  coordinates)  and  the  transformation  matrix.  This  matrix  is  necessary  to  convert  the 
height  information  to  world  coordinates  so  it  may  be  used  by  the  foot  orientation  algorithm. 

The  mask  is  used  to  identify  which  type  of  geometry  the  intersection  test  is  for.  This 
allows  Aquarobot  to  distinguish  between  stepping  on  hard  ground  arid  water,  and  perform 
accordingly. 

The  discFunc  is  a  discriminator  callback  function  which  is  invoked  upon  all  successful 
intersections.  This  is  a  user  defined  function  which  provides  a  more  powerful  means  to 
control  intersections  than  with  the  mask  test  alone.  Currently,  this  option  is  not  being  used. 

P^ormer  has  provided  the  desired  tools  to  extract  the  necessary  information  from  any 
graphics  scene.  We  must  now  determine  how  best  to  utilize  these  tools  to  obtain  a  realistic 
simulation  that  runs  in  real  time. 

1.  A  Single  Center  Segment 

The  first  attempt  at  getting  the  foot  pads  to  contour  to  uneven  terrain  was  to 
project  a  single  segment  from  the  center  of  the  foot  in  the  -Z  direction  (that’s  +Z  in  the 
conventional  robotics  coordinate  system)  and  determine  the  XYZ  coordinate  and  the 
normal  P  at  the  point  of  intersection.  This  data  was  then  used  to  set  the  height  and 
orientation  of  the  foot  pad  (Figure  IS). 

a.  Results 

This  method  was  very  rapid  and  worked  well  when  the  terrain  was  designed 
with  large  sloping  primitives  (polygons)  and  the  normals  between  two  adjacent  primitives 
did  not  differ  very  much.  When  this  method  was  used  with  step  changes  in  height,  the  visual 
results  were  displeasing  (Figure  16). 
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Figure  15:  Foot  Placement  With  a  Single  Segment  at  the  Center  of  the  Foot 


Figure  16:  Result  of  Using  a  Single  Segment  From  the  Center  of  the  Foot 


2.  Multiple  Segments 

The  next  approach  in  determining  foot  placement  evolved  from  the  first 
Multiple  intersecting  segments  were  organized  in  a  manner  to  extract  more  information 
from  the  terrain  while  taking  maximum  advantage  in  the  use  of  Pnformers  pfPlane 
(Chapter  m,  Section  B). 
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a.  Foot  Pad  Divisions 

The  intersection  segments  (pfSegs)  are  arranged  in  three  groups  wfoch 
divide  the  foot  pad  into  equal  sectors  of  120  degrees.  Hgure  17  shows  the  general  pattern 
used  for  the  placonent  of  the  intersecting  segments. 


Figure  17:  Placement  of  Segments 

This  pattern  allows  for  the  100%  detection  of  objects  which  are  greater  than 
20  cm  in  diameter.  Objects  less  than  20  cm  may  go  undetected  by  the  simulation  if  stepped 
on  in  just  the  right  manner.  The  shaded  area  of  Hgure  17  depicts  the  “dead  zone”  of  the  foot 
pad  where  objects  will  be  undetected. 

b.  Creating  an  Artificial  Plane 

Dividing  the  foot  pad  into  3  sectors  was  chosen  on  the  concept  that  any  3 
non-linear  points  define  a  unique  plane.  If  the  highest  identified  point  from  each  sector  is 
used,  a  plane  can  be  defined  on  which  to  place  the  foot  Thus  the  orientation  problem  is 
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reduced  down  to  the  single  segment  solution.  This  ^)proach  eliminates  the  problem  shown 
in  Figure  16,  but  is  still  not  adequate  enough  for  an  accurate  simulation  (Figure  18). 


Figure  18:  Foot  Orientation  Using  an  Artificial  Plane 


c.  Correcting  the  Artificial  Plane 

Once  an  artificial  plane  has  been  established,  it  is  necessary  to  examine  the 
foot  pad  oriented  to  this  plane  and  check  for  collisions  with  the  surrounding  geometry.  If 
such  collisions  exist,  then  it  is  necessary  to  recompute  the  artificial  plane.  Here  is  a 
description  of  the  algorithm  used  for  foot  placement  on  uneven  terrain: 

•  Determine  die  highest  point  in  each  sector  of  a  foot  pad. 

•  Create  a  pfPlane  (Chapter  m.  Section  B)  using  the  three  highest  points. 

•  Determine  the  hdght  of  the  pfPlane  at  the  crater  of  the  foot  pad. 

•  Set  the  foot  pad  to  conform  to  the  pfPlane  height  and  orientation. 

•  Calculate  the  height  at  each  of  the  locations  used  to  projea  the  pfSegs  based  on 
the  new  orientation. 

•  (Compare  the  height  at  each  location  with  die  actual  ground  height  returned  from 
the  intersection  test 

•  For  each  sector,  if  the  ground  height  is  greater  than  the  foot  pad  height  find  the 
point  with  the  greatest  difference  and  substitute  this  point  into  the  pfPlane  equation  to 
determine  a  new  plane. 

•  Set  the  foot  pad  to  the  corrected  pfPlane  orientation. 

d.  Results 

After  a  single  iteration  of  adjusting  the  ground  plane,  the  simulation  was 
able  to  overcome  the  previous  two  anomalies  and  produce  a  fairly  accurate  simulation 
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(Figure  19).  But  this  method  too  has  its  drawbacks.  When  traversing  terrain  that  contains 


Figure  19:  Final  Foot  Placement 


raised  obstacles  that  lie  perpendicular  to  one  of  the  lines  that  divide  a  foot  pad,  a  unique 
situation  arises  if  the  three  contact  points  for  detennining  the  artificial  plane  h^pen  to  fall 
on  one  half  of  the  foot  pad  (Figure  20). 


Figure  20:  Result  of  Having  all  Three  Ground  Contact  Points  on  One  Side  of 

the  Foot 

Though,  this  feature  is  not  visually  or  physically  correct,  it  does  not 


invalidate  the  simulation  as  a  tool  for  testing  the  control  software.  The  visual  simulation 
still  sets  the  foot’s  ground  contact  flag  to  inform  the  gait  algorithm  to  stop  moving  the  foot 
independent  of  the  foot’s  orientation. 
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3.  Speeding  Up  the  Process 

Other  than  defining  a  pfCylinder  to  speed  up  the  intersection  traversal  of  the 
terrain  node,  two  flags  were  added  which  reduce  the  number  of  times  the  intersection 
traversal  is  performed.  The  first  is  a  ground  contact  flag.  If  the  foot  is  on  the  ground,  then 
the  routine  for  foot  placement  is  not  necessary.  The  second  flag  defines  foot  vertical 
motion.  Checking  to  see  if  the  foot  is  touching  the  ground  is  only  necessary  if  the  foot  is 
being  lowered.  These  two  flags  caused  the  simulations  execution  time  to  increase  from  15 
frames  per  second  (FPS),  to  30  FPS. 
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VI.  RESULTS 


A.  SIMULATION  DESCRIPTION 

The  Aquarobot  simulation  is  a  real-time,  3-D  coiiq>uter  simulation  running  on  a 
Silicon  Graphics  Workstation.  The  Simulation  is  currently  running  at  approximately  30 

frames  per  second.  Additional  hardware  utilized  is  a  Spaceball^  for  the  position  of  the 
viewing  volume,  SGTs  Dial  and  Button  indicators  for  the  control  of  the  camera  boom,  and 
HOTAS  flight  control  devices  for  Aquarobofs  center  of  body  commanded  velocity 
(velocity  may  also  be  controlled  using  the  keyboard.  See  Below).  Software  needed  for  the 
simulation  is  SGFs  Performer,  for  its  rapid  drawing  and  intersecting  routines  and  the 
NPSGDL  loader  which  enables  Performer  to  di^lay  the  models. 

1.  Keyboard  Responses 

The  following  describes  the  keyboard  refuses  recognized  by  the  simulation: 

•  ESC  key  -  exits  from  the  simulation 

•  FI  key  -  Displays  system  characteristics 

•  F2  key  -  Enables  or  disables  texturing 

•  F3  key  -  Toggles  fog  on/off  (underwater  effect) 

The  arrow  keys  control  the  velocity  of  the  torso.  The  re^nses  are  0%  to  100%  of  the 

maximum  simulation  speed  in  increments  of  20%. 


1.  A  q)acebaU  is  a  6  degree  torque  sensing  device 


VIL  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  RECOMMENDATIONS 

Work  is  being  done  to  create  a  virtual  environment  for  AUV’s  [Ref.  14]  to  test  hardware 
and  control  software  performance  in  a  controlled,  yet  realistic  manner.  This  same  theory 
may  be  applied  to  walking  machines.  This  thesis  demonstrated  the  ability  to  distinguish 
between  solid  ground  and  water,  the  two  extremes.  It  is  also  possible  to  model  the  terrain 
to  exhibit  certain  characteristics  in  between  and  also  to  model  foot  sinkage  and  slippage.  I 
believe  that  the  development  of  a  virtual  environment  that  has  the  capability  of  providing 
foot  sinkage  and  foot  slippage  information  in  die  form  of  reaction  forces  to  the  placement 
of  the  foot  will  enhance  the  development  of  fully  autonomous  walking  robots. 

B.  FUTURE  WORK 

This  thesis  is  just  the  beginning  of  creating  a  complete  simulation  for  the  testing  of 
control  software.  Other  areas  that  need  research  are: 

•  Detecting  collisions  between  limbs 

•  Static  forces  acting  on  Aquarobot  from  the  tether  cable 

•  Modeling  the  ball  joint  limit  and  the  feedback  to  the  gait  algorithm 

Another  area  of  research  is  the  integration  of  walking  robots  into  defense  simulations 

to  investigate  their  use  in  mine  hunting  operations. 
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APPENDIX  A;  SIMULATION  SOURCE  CODE 


//*********** 

//FE£NAME: 

//PURPOSE: 

// 

// 

// 

//NCnE: 

//AUTHOR: 

//DATE: 

//COMMENT: 

//UPDATE: 

//*****•*•*•• 


pfaqua.C 

This  file  (XMitains  the  fiinctkxis  to  set  up  the  geometry  for 

the  Aquaiobot  model,  determinii^  ground  contact  and  detennining 

foot  pad  orientation 

This  program  is  written  in  C-h-  utilizing  Perfonner  1.0 
John  Goetz 
TOFebniary  1994 


#include  <sidlibJi> 

#include  <stdiah> 

#include  <stting.h> 

#include  <glAlevice.fa> 

finclude  “SGIwindowcam.H” 

#include  ‘Irobot.gldbals  Ji** 

«incliide‘‘loadGDLJi’' 
include ‘^f.h” 

idefineTERRAIN.MASK  0x0008 
idefimWATEILMASK  0x0004 
idefine  RAYS  JPER^SECTOR  10 
idefineFOOTPADJlADIUS  22.Sf 

static  void  OpenPipeline  (pff^  *p); 

static  void  DtawChannel  ^Channel  ^channel,  vdd  *daia); 

static  void  CullChannel^n^uumd  *chan,  void  *data); 

voidgtoondjcontBCt(pfDCS  *DCSIiiik[d][4]); 

voidset_initial_foot_positkm(pfDCS  *DCSlink[6][4]); 

void  set_foot_intecsectk)njsegmentsO>fSeg  **segroe^  int  leg); 

void  otient_foot(pfIsea  di^3*RAYS  J^_SE&rOR+l].  int  leg); 

voidmove_caineta_boom(pflX}S  *DCSboom[3]}; 

void  read_maiBtia]sO; 

pfGroup*  tead.tBtiainO: 

pfGroup*  boi]d_aquarobot(pfDCS  ^Tnse.  pfDCS  *DCSlink[6][4],  pfDCS  *DCSboom[3]); 


static  pfScene  *scene; 
static  pfLight  *Sun,  *Sun2; 
static  pfFbg  *watBr; 

pfSeg  **segment  =  (pfScg**)pfMttlloc(sizeof(pfSeg*)  *  (3  *  RAYS_PER_SECTOR) JWLL); 
static  SharedData  ^Shared; 
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void  mainO  { 

pfPipe  *p; 
pfChannel  *chan; 
piGroup  *aquarobotl; 
pfGroup  *terrain; 
pfDCS  *aquabase: 
pflXTS  •DCSUnk{61(4]; 
pfDCS  *DCScambooin(3]; 
pfEaithSky  *eSky: 


//  initialize  Performer 
pfInitO; 

//  Allows  multiple  threads  to  be  forked.  One  for  the  application,  one  for 
//  the  Draw  process  and  one  for  the  Cull  process 
pfMultiprocess(PFMP_DEFAULT); 

H  This  prevents  multiple  threads  from  being  forked. 

//  pfMultiprocess(PFMP_APPCULLDRAW); 

//  Establish  shared  memmory  before  calling  pfConfigO  so  that  all  forked 
//  threads  w^  know  where  it  is. 

Shared  s  (S.hatedData*)pfMalloc(sizeof(SharedData),  pfGetSharedArenaO): 
Shared->exitFlag  =0; 

Shared->resetFIag  s  0; 

Sharedr>pfStats  =0; 

Shared->pfFog  s  O; 

pfConfigO; 

scene  =  pfNewSceneO: 
read_mateiialsO; 

//  Load  in  the  terrain  model  for  robot  to  walk  on  and  add  it  to  the  scene  as 
//  the  first  child  (index  0).  This  enables  the  terrain  to  be  accessed  redily 
//  by  the  ground  contact  algoithms. 


terrain  =  read.terrainO; 
pfAddChild  (scene,  terrain); 

//  Build  the  Aquarobot  model 
aquabase  =pfNewDCS0; 

aquarobotl  =:  build_aquaiobot(aquabase,  DCSlink,  DCScamboom); 

//  Add  the  robot  to  the  scene 
pf^dChild  (sceneaquarobotl); 


//  Configure  and  open  a  graphics  pipeline 
p  as  pfeetPipefO); 
pfInitPipe(p,  OpenPipeline); 

//  Set  desired  frames  per  second 
pfFrameRate(30.0f); 
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//  Get  and  configure  a  viewing  channel 
chan  =  pfNewChanfp); 

//  Set  the  channels  Draw  and  Cull  functions 
pfChanDrawFunc(chan,  DiawChannel); 
pfChanCullFuncfchan,  CullChannel); 

//  Establish  dimentions  for  the  viewing  frusmun 
pfChanScene(chan.  scene); 
pfChanNearFarfchan.  O.lf,  6000.0f); 
pfChanFOVfchan,  45.0f,  -l.Of); 

//  Establish  orientation  for  viewing  firustrum 
pfSetVec3(Shared->view.hpr,  90.0f.  0.0f,  O.Of); 
pfSetVec3(Shared->view.xyz,  650.0f.  O.Of.  20.0f): 

//  Create  an  earth/sky  model  that  draws  sky  and  horizon 
eSky  =  pfNewESk^O;  _ 

pfESkyModefeSky,  PFES_BUFFER_CLEAR.  PFES_SKY_CLEAR); 
pfThanESkyfchan.  eSky); 

//  pfChanTravMtJdefchan.  PFCULL_VIEWIPFCULL_GSET.  NULL); 

//  This  pfS^'tic  tiTFrame  are  necessary  to  establish  die  graphics  scene  so 

H  that  the  pfSegsIswsNodt-  routine  can  be  used  in  set_initud_foot_position. 

pfSyncO; 

pfFiameO; 

//  This  restart  gets  the  X  and  Y  positions  of  the  footpads 
iestart_robot(aquabase,  DCSlink); 

//  The  Z  position  of  the  footpads  is  set  based  on  tenain  information 
set_initial_foot_position(DCSlink); 

//  Move  robot  is  called  so  that  the  joint  angles  may  be  calculated  based 

//  on  the  correct  foot  height 
move_robot(aquabase,  DCSlink); 

//  Start  the  continuous  loop 
while  (!Shared->exitFlag)  { 


/*  Go  to  sleep  till  next  frame  time  *! 
pfSyncO; 

/*  Set  view  parameters.  */ 

pfChanViewfchan,  Shared->view.xyz,  Shared->view.hpr); 

I*  initiate  cuU/draw  fcr  this  &ame  */ 
pfFrameO; 

I*  Update  robot  position  *! 
ground_contact(DCSlink}; 
move_robot(aquabase.  DCSlink); 
move_camera_boom(DCScamboom); 


if  (Shared->resetF]ag)  { 

pfSetVec3(Shared->view.hpr,  90.0f,  0.0f,  0.00; 
pfSetVec3(Shared->view.xyz,  650.0f,  O.Of,  20.00; 
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resia]t_robot(aquabase.  DCSlink); 
set_initial_foot_position(DCSlink); 
Shared->resetFlag  *  0; 

) 


} 

/*  tenninate  cull  and  draw  processes  (if  they  exist)  */ 
pfExitO; 

/*  exit  to  operating  system  */ 
exit(0); 


} 


//  OpenPipelineO  -  create  a  pipeline:  setup  the  window  system. 

//  the  IRIS  GL,  and  DUS  Performer.  This  procedure  is  executed  in 
//  the  draw  process  (when  there  is  a  separ^  draw  process). 


static  void 

OpenPipeline  (pfPipe  *p) 

{ 


/*  negotiate  with  window-manager  */ 

scniselect(0); 

fofegtound(); 

/*  set  up  window  */ 
pre^tion(178, 779. 491, 952); 
win^)en(“AquatoboO; 

/*  negotiate  with  GL  */ 
pOnitGfx^); 

r  Set  Z-buffer  dq)th  based  on  hardware  */ 
if  ( int(getgconfig(GC_MS_SAMPLES))  >  0 ) 

Isetdepth  ( getgconfig(GC_MS_ZMIN),  getpx)nfig(GC_MS_ZMAX) ); 
else 

Isetdepth  ( getgconfig(GC_ZMIN),  getgconfig(GC_ZMAX) ); 

f*  initialize  events  to  be  placed  on  the  que  */ 
inidalizeO; 

/*  create  two  light  sources  */ 

Sun  =  pfNewLight(pfGetShatedAtenaO); 

Sun2  s  pfNewLight^fGetSharedArenaO); 
pfLight^s(Sun,0.Sf,0.5f.  l.()f,0.0f); 
pfLightPos(Sun^  O.Sf,  -O.Sf,  1.0f,  O.Of); 

/*  create  a  default  Dghting  model  */ 
pfApplyLModel(pfNewLModel(pfGetSharedArenaO)); 

pfLightOn(Sun); 

pfLightOn(Sun2); 

/*  oiable  culling  of  back-facing  polygons  */ 
p«:ullFace(PFCF_BACK); 
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/*  Set  up  fog  parameiers  to  simulate  an  underwater  environment  */ 

pfEnable(PF^_FOG); 

water  =  pfNewI^g(pfGetSharedArena()); 

pfFogTjTJe(  water,  PFFOG_PIX_EXP); 

pfFogColor(water,  O.Of.  0.385f,  0.464f); 

pfFogRange(water.  O.Of,  SOOOO.Of); 


I* 

*  CuUCiiannelO  -  traverse  the  scene  ^aph  and  generate  a 

*  display  list  for  the  draw  process.  This  procedure  is 

*  executed  in  the  cull  process. 

*1 

static  void 

CullChannel(pfChannel*,  void*)  { 

/* 

*  pfDiawGeoSet  or  other  display  listable  Performa  routines 

*  could  be  invoked  before  or  after  pfCull() 

*/ 

pfCuUO; 

} 


static  void  DrawChannel  (pfChannel  *chan.  void*)  { 

//  pfCoord  *temp  =  (pfCoord*)data: 
static  pfVec4  backdrop; 

//  DfSetVec4(hackdi»p.  O.Of,  0.385f.  0.464f.  l.Of); 
pfSetVec4(backdrop,  l.Of,  1.0f,  1.0f,  1.0f); 
phCle^badcdrt^,  PFCL_CLEARCZ); 

/*  rebind  light  so  it  stays  fixed  in  position  */ 

pfLightOn(Sun); 

pfLightOn(Sun2); 


/*  draw  Performer  throughput  statistics  */ 
if  (Shared->pfStats) 
pfDrawChwStats(chan); 

//  if  (Shared->pfFog) 
pfApplyFog(water); 

//  else 

//  pfCleatChan(chan); 

//  Invt^e  Performs  draw-processing  for  this  frame 
pfDrawQ; 

Check_Que(Shared); 

)  //  end  DrawChaimel 
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//  Build.aquarobot  sets  the  DCS’s  so  that  all  the  kp  are  connected 
//  This  does  not  set  the  initial  posture 

pfGroup*  build.aquaroboUpfDCS  *base.  pflXTS  ‘DCSlinkieiW,  pfDCS  •DCSboom[3])  { 

register  int  i; 

pfGtoup  *duininy; 

pfGroup  *shouldaH,  *shoulderM; 

pfGroup  *upperJegH,  *upperJegM; 

pfGroup  ‘lowerJegH,  *lower_legM; 

pfGroup  *foot_pad: 

pfGroup  *legnuniber[6]: 

pfSCS  •shoulderSCSffi], 

*upper_kgSCS[6].  *lowerJegSCS[6], 

*cameia_boomSCS(3]. 

*scsl; 

pfLOD  *tonoLOD.  '^shoulderLOD. 

♦upperJegLOD.  *lowerJegLOD; 

pfMattut  rot.mat,  rot_niat2.  trans.mal; 

dummy  s  pfNewGroupO: 

/*  The  torso  image  is  defind  with  the  X  axis  comming  out  of  the  bottom  of  the 
robot  (this  is  the  gl  Z  axis)  so  it  must  be  rottued  90  deg  about  the  Y  axis 
for  it  to  be  orient^  properiy.  *! 

pfMakBRotMat(rot_mat,  90.0f,  0.0f,  0.0f,  l.Of); 
pfMak^tMat(rot_mai2. 180.0f.0.0f.  1.0f,0.0f); 
pfPreMultMat(rot_mat2,  rot.mat); 
scsl  =  pfNewSCS(rot.mat2); 
pfAddChild(dummy,  scsl); 


toisoLOD  s  pfNewLODQ; 
pfLODRang^torsoLOD,  0, 1.0f); 
pfLODRange(trasoLOD,  1, 100.00; 
pfLODRange(unsoLOD,  2, 10000.00; 
pfAddChild(dummy,  base); 
pfAddChild(base,  torsoLOD); 

pfAddChild(torsoLOD.LoadGDL2(“models/Robotics/pftorsoLODagdl”)); 
pfAddChild(torsoLOD,  LoadGDL2(“models/Robotics;^ftra5oLODM.gdl”)); 


shoulderH  s  LoadGDL2CTnodels/Robotics^fshoulder_IinlcLODH.gdl’*); 
shoulderM  =  LoadGDL2(‘*models/Robotic^fshoulder_linkLODM.gdl’'); 
ui^JegH = Loa(iGDL2C1nodels/Robotics/|^ipperJegLODH.gdl^; 
uppci-legM  s  LoadGDL2(''models/Robotic^fop^_legLODM.gdl^; 
lowcrJegH  =  LoadGDL2(“models/Robotics^flower JegLODILgdl”); 
lowerJegM  s  LoadGDL2(“models/Roboticsi4)flowa'_legLODM.gdl”); 
footjpad  s  LoadGDL2('*models/Roboti(^ffoot_pad.gdl’’); 


kgnumber[0]  s  LoadGDL2(“models^boticsA)umplatel.gdl’0 
legnumber[l]  =  LoadGDL2(“models^boticsMumplate2.gdl”) 
legnumber[2]  =  LoadGDL2(“mo(kls)^botics^amplate3.gdl”) 
kgnumber[3]  -  LoadGDL2(“models/RoboticsMumplate4.gdl”) 
kgnumber(4]  s  LoadGDL2rinodels/Robotics)humplateS.gdl”) 
legnumber[Si »  LoadGDL2(“models^bodc^umplate6.gdl”) 
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foi(i  =s  0;  i<6;  i++)  1 


/*  Rotate  and  translate  shoulder  so  it  will  be  rendered  correctly  V 
plMakeRotMat(rot_inat.  (float)i*60.0f,  O.Of,  O.Of,  1.00: 
pfMakeTransMat(trans.mat,  LINKOLENGTH,  O.Of,  0.00: 
pfPreMultMatCrot.mat,  trans.mat): 
shoulderSCS[i]  =  pfNewSCS(rot_mai): 

/*  Add  DCS  to  the  SCS  so  the  shoulder  can  move  */ 

DCSUnkWIO]  =  pfNewDCSO: 
shoulderLOD  a  pfNewLODO: 
pfLODRange(shoulderLOD.  0. 1.00: 
pfLODRange(shoulderLOD.  1, 100.00: 
pfLODRange(shoulderLOD,  2. 10000.00: 
pfAddChildfbase,  shoulderSCS[i]): 
pfAddChild(shouldaSCS(i].  DCSlink[i][0]): 
pfAddChild(DCSlink[il[0].  shoulderLOD); 
pfAddChild(shouldeiLOD.  shoulderH); 
pfAddChild(shoulderLOD,  shoulderM); 

/*  Translate  out  from  shoulder  DCS  to  the  next  link  */ 
pfMakeTiansKfat(trans_mat.  LINKILENGTH,  O.Cf.  0.00: 
pfMakeRotMatfrot.mat,  -90.0f.  l.Of,  0.0f,  0.00: 
pa*reMultMat(tians_mat,  rot.mat): 
upper JegSCS[i]  a  pfNewSCS(tians_mat): 

IX^liiik[i][l]  a  pfNewDCSO: 
uppo'JegLOD  a  pfNewLODQ: 
pfLODRange(upper_legLOD,  0, 1.00; 
pfL0DRange(upper_1^0D,  1, 500.00; 
pfLODRange(in^J^LOD,2, 10000.00: 
pfAddChild(DCSlink{i][0].  up^JegSCSd]); 
pfAddChild(iq^JegSCS[i],  iX^lii^i][ll);  //  DCS  to  move  upper  leg 
pfAddChild(DCSlink{i][l].  upperJegLOD); 
pfAddChildfupperJegLOD,  upporJegH): 
pfAddChild(iii^JegLOD,  upperJegM); 

/*  Translate  out  from  upper.leg^DCS  to  the  next  link 
pfMakeTransMat(trans_mat.  LINK2LENGTH,  OXX,  0.00: 
lowerJegSCS[i]  a  pfNewS^(tians  mat); 

DCSlink[i][2]  a  pfNewDCSQ: 
lowerJegLOD  a  pfNewLODO: 
pfLODRangeflowaJegLOD.  0, 1.00: 
pfLODRange(lower_legLOD,  1, 500.00: 
pfLODRange(lowerJegLOD,  2, 10000.00; 
p£AddCluld(DCSlink[i][l].  lowerJegSCS[i}); 
pfAddChild(IowerJegSCS[i],  DCSlink[i][2])://  DCS  to  move  lower  leg 
pfAddChild(DCS]fr&[i][2],  lowerJegLOD); 
pfAddChild(DCSIink[i][2},  legnumbeiti]); 
pfAddChildUowerJegLOD,  lower JegH): 
pfAddChild(IowerJegLOD,  lowo'JeghO: 

/*  Attach  foot  pad  DCS’s  to  the  world  not  Aquarobot*/ 

DCSlink[il[31  a  pfNewDCSO; 
pfAddChildfscsl,  DCSlink[i][3]); 
pfAddChild(DCS]ink[i][3],  foot_pad); 

pfFlattenfdummy); 

)  //  end  for  statement  V 

pfMakeTransMat(trans_mat,  O.Of.  O.Of.  -87.00: 
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cainera_booinSCS[0]  s  pfNewSCS(trans_mat); 

DCSboom[0]  =  ptNewEiCSO; 
pfAd(lChild(base,  cainera_boomSCS[0]); 
p£AddChild(caniera_booinSCS[0],  DCSbooni[0]); 
pfAddChild(DCSboom[0],  LoadGDL2(“inodels/Robotics/pfcamera_base.gdl”)); 

pfMakeTransMaKtrans.mat.  5.0f.  O.Of.  O.Of); 
pfMakeRotMat(iot_inat.  -90.0f.  l.Of.  O.Of,  O.Of): 
pfPreMultMat(tians_mat  rot.mai): 
camera_booinSCS[l] »  pfNewSCS(tnins_iiiat): 

DCSboom[l]  ®  pfNewEfcsO; 
p£AddChild(DCSboom[0],  caniera_booinSCS[l]); 
p£AddChild(canieta_baomSCS[l].  DCSbooin{l]); 
pfAddChild(DCSbooin[l],  LoadGDL2C‘m^els/Robotics^fcamera_linkl.gdl”)); 

pfMakeTransMat(Grans_mat.  45.0f,  O.Of,  0.00: 
caineia_booniSCS[2]  =  pfNewSCSftrans.mat); 

DCSbooin[2]  =  pfNewEiCSO; 
pfAddChjld(DCSbooin[l],  camera_boofnSCS[2]); 
pfAddChild(cafnera_booinSCS[2].  DCSboomi2]); 

p£AddChild(DCSbooin[2],  LoadGDL2(“modeis/Robotics4>fcainera_liiik2.gdl’*)); 

return  dummy; 

}  //  end  build_aquarobot 
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void  giound_coniact(pflXrs  *DCSIink[6][4])  { 

stadc  long  nscgs  =  3  •  RAYS_PER_SECTOR; 
loiig  isect; 

static  pflsect  result^  *  RAYS_PER_SECTOR]: 

static  pfCylinder  •cyl  =  (pfCylinder*)p£Malkx:(sizeof(pfCyliiider)J4ULL); 

pfVec3  head,  head90; 

float  dotp; 

pfMatrix  pitch,  roll; 

for  (int  leg  =  0;  leg  <  6;  leg-H-)  { 

if  ((!foot_dataDeg].ground_contact)  && 

(foot_data(ieg].diiwtion))( 

set_foot_intersection_segments(seginent.  leg); 

pfCylAioiindSegsfcyl  segment,  nsegs); 

pfSetVec3(cyl->center.  foot_data0eg].foot_xy2[2],foot_dataneg].foot  xyz[0], 
foot_data(leg].foot_xyz[  1  ]); 
cyl->halfLength  ■  LINK4LENGTH; 
cyl->radius  =  FOOTPAD_RADrUS; 
f*  find  intersection  with  terrain  */ 
iseaa 

pfSegslsectNode(pfGetChild(scene.  0).  segment,  nsegs.  PFTRAV  IS  PRIMI 
PFTR/^ JS.CUIi JACKIPFTRAVJS  NORM, 
imtAIN.MASK. 
cyl,  result,  NULL); 

if  ((isect)  &Sl 

(foot_dataneg]ioot_xyz[ll  -  tesult[0].pomt[21  <  9,00)  { 
orient_foot(result,  leg); 

pfMakeTransMat(foot_data{leg],foot_mat,foot  daia(]eg].foot  xyz[0}, 
foot_dataDeg]ioot_xyz(2].  •foot_data(leg]ioot_xyz[l]);  ” 

//  Set  heading  of  foot  pad.  Always  000 

head[0]  =  0.0f; 
head[l] » l.Of; 
head[2]»0.0f; 

//  Determine  foot  roll 

dotp  =  PFDOT_VEC3(head,  foot_data(leg].noimal); 
pfMakeRotMat(ioll,  (pfAicCos(dotp)  -  90.00, 0.0f,  I.0f,  0.00; 

//  Set  heading  of  foot  pad  90  degrees 
head90[0] » 1.0f; 
head90[l]»0.0f; 
head90(2]«0.0f; 

//  Determine  foot  ntch 

dotp  =  PFDOT_VEC3(head90,  foot_dataOeg].notmal); 
pfMakeRotMat(pitch,  (90.0f  -  pfArcCos(doi»)),  l.0f,  O.Of,  0.00; 
pfPostMaltMat(pitch.  roll); 
pfPreMultMat(foot_data[leg].foot_mat,  pitch); 

//  Set  the  foot  pad  DCS  to  the  calculated  orimtation 

pfDCSMatiix(DCSlink[leg][3],  foot.dataOeglibot.mat); 

}  //  end  if  statement  (isect) 

)  //  end  if  statement  (not  foot  contact) 

}  //Old  for  statement 
}  //  end  ground.contact 
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void  set_initial_foot_position(pflX^  *DCSlink{6][4])  ( 

long  nsegs  =  3*RAYS_PER_SECTOR: 
long  isect; 

pfisect  resultO  *  RAYS_PER_SECTOR]: 
pfVec3  head.  head90; 
float  (k^: 
pfMairix  pitch,  roll; 

for  (int  leg  =  0;  leg  <  6;  leg++)  { 

set_foot_intersection_segments(segment,  leg); 

I*  find  inteisection  with  terrain  */ 
isect  s 

pfSegsIsectNodefpfGetChihKscene,  0),  segment,  nsegs,  PFTRAV_IS_PRIMI 
PFrRAV_IS_CULL_BACKIWTOAV_rS_NORM. 
TERRAIN.MASK, 

NULL,  result.  NULL); 


if  (isect) 

orient_foot(result.  leg); 
else  ( 

foot_dataaeglioot_xyz(l] »  LINK4LENGTH; 
PFSET_VEC3(foot_aaa(leg].normal,  0.()f,  0.0f.  1.0f); 

) 

pfM2dmTtaiisMat(fooc_daia(]eg]ioot_inat.  foot_dataOeg]  Jbot_xyz(0], 
foot_dataDeg]ioot.xyz{2],  •foot_dataneg]ioot_xyz[ii); 


//  Set  heading  of  fix)t  pal  Alwt^  (XX) 
head[0]»0X)f; 
head[l]»1.0f. 
head(2]»0.0f; 

//  Determine  foot  roll 

doip  «  PFDOT_VEC3(heal  foot_data(lM]  jiarmal); 
pfMakeRotMat(ioll,  0>fAicC^doqi)  >  90.00. 0.Of.  1.0f,  0.00; 

//  Set  heading  of  fixx  pad  90  degrees 
head90[0] « l.Of; 
head90(l]s0.0f; 
head90(2]s0.0r; 

//  Detemine  foot  pitch 

doip  a  PFDOT_VEC3(head90,  footjdatafleg]  jwmud); 
pfMakeRotMat(pitch,  (90.0f  •  pfAtcCos(dotp)),  i.0f,  0.0f.  0.00; 
pfPostMultMtt(pitch,  rcdl); 
pfPrcMaltMat(footjdaia(leg].foot_inat,  pitch); 

//  S^  the  foot  pad  DCS  to  the  calculated  orientation 
pfDCSMatrix(DCSlink[leg][3],  foot_data(leg].foot_inat); 

) // end  for  siatHnent 
}  //  end  set_initial_foot_position 
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//  This  function  establishes  the  location  and  direction  of  the  intersection  segments  being 
//  projected  from  each  foot 

void  set_foot_intersection_segments(pfSeg  **segment.  int  leg)  ( 

static  pfVec3  foot_segs_xyz(3]IRAYS_PER_SECTORl; 
static  float  angle  ®  120.0f  /  (RAYS_P^_SECTOR  - 1); 
static  int  init «  1; 
int  count  s  0: 
float  s.  c; 

pfVec3  temp_vecl.  temp_vec2; 


if(init)  { 

for  (int  sect  =  0;  sect<3;  sect-H-)  ( 
pfSinCos(120.0f*sect+60.0,  &s.  &c); 

PFSET_VEC3(foot_segs_xyz[sectl[01.  -s*3.0f.  c*3.0f,  0.00: 
segment[count-H-] » (pfSeg*)pfMtd]oc(sizeof(pfSeg),  NULL); 

for  (int  nseg  =  0;  nseg<RAYS_PER_SEC?TOR  - 1;  nseg++)  { 
pfSinCos((angle*nseg>Kangle/2.0f)+(120.0f*sect).  &s,  &c); 

PFSET_VEC3(foot_segs_xyz(sectl(nseg+ll.  -s*FOOTPAD_RADIUS.  c*FOOTPAD_RADIUS.  0.00: 
segment[count-H-l  =  (pfSeg*)pfMaiioc(sizeof(p^eg),  NULL); 

} 

) 

init  =  0; 
count  sO; 

} 

temp_veci[0]  =  foot_dataneg]ioot_xyz[21; 
temp_vecl[l]  =  foot_data(leg]ioot_xyz[0]; 
temp_vecl[2] »  foot_data{legi.foot_xyz{l]  +  5.0f; 

/*  make  several  rays  looking  “down”  at  tereain  */ 

for  (int  sect »  0;  sect<3;  sect-H-)  ( 
for  (int  nseg  *  0;  nscg<RAYS_PER_SECnX)R;  nseg-H-)  { 

PFADD_VEC3(seginait[count]->pos,  temp_vecl,  foot_segs_xyz[sect][nseg]); 

PFSET_VE<23(segment(count]->dir.  O.Of,  0.0f,  -1.00: 

pfNoniiidizeVec3(segmait(count]->dir): 

segment[count]->length  =  ^.Of; 

count-H-; 

} 

} 


)  //  end  set_foot_intersection_segments 


//  This  function  detetmines  the  pfPlane  on  which  to  orient  the  foot  pads 
void  <ment_foot(pfIsect  daia[3*RAYS_PER_SECrOR+l],  int  kg)  { 
pfVec3  contact_points(3]; 

statk  pfPlane  Aground  s  (pfPlane*)pfMaUoc(sizeof(pfPIane),  NULL); 
int  count  =  0;  //  Keeps  track  of  the  number  of  segmems  that  needs 
//  to  be  considered 

pfVec3  head[3][RAYS_PER_SECTOR].  head90; 
float  dotp; 

float  delia_height[3][RAYS_reR_SECTORl; 

float  deepest »  O.Of; 

float  sh,  ch; 

int  sector  sO; 

int  seg_tay  =  0; 

pfMatnx  m2,  m3: 

static  float  angle  s  120.0f  /  (RAYS_PER_SECTOR  - 1); 
static  pfSeg  *foot » (pfSeg*)pfMalloc(sizeof(pSeg) jIULL); 

for  (int  sect = 0:  sect<3:  sect++)  { 

PFSET_VEC3(contact joimstsect],  0.0f,  0.0f,  0.00; 

for  (int  nseg  =  0;  nscg<RAYS_raR_SECTOR;  ns^-H-)  { 
if  (data[count].flags  &  (PFIS.POIN11PFIS_NORMIFFIS_PRIM))  {  U  Data  is  good 
pfXf(HinPt3(data[count].point,  data(count].point,  daia[count].xform); 

if(data{count]jK)int(2]  >  CQntactjpoints[sect](2]) 

PFCX)PY  Vl^(c(mtact_points[sect],dataIcount].point); 

1 

count-H-; 

} 

} 


PFSET_VEC3(foot->dir,  0.0f,  0.0f.  -LOO; 
foot->length  s  50.0f; 

foot->pos[0]  =  footjdata(kglioot_xyz[2]; 
foot->posilj  s  foot_data[kg]ibot_xyzioj; 
foot->pos[2]  s  foot_data[kgiioot_xyz[l]; 

pfMakePtsPlane(ground,  contact_poims[2],  contact_points[l],  contact_points[0]); 
pfNonnaiizeVec3(ground->nonnal): 

if  (gtound->noniial[21  <  0.00  { 

pfMakePBHane(gtound,  contact_points[0],  contact jpointsd],  contact_points[2]); 
pfNorma]i2eVec3(ground->nonnal); 

} 


count  =  0; 

if(l^egIsectPlane(foot,  ground.  &foot_data(leg].foot_height)  =»  PFIS.FALSE) 
ptintf(‘7^o  ground  intersection  1  for  leg  %i\n  ,  leg); 

head[0][0][0]»0.0f; 

head[0][0][l]sL0f; 

head[0][0][2]»0.0f; 

dotp  sr  ProOT_VEC3(head(0][0],  ground->normal); 
pfMakeRotMat(m2,  (pfArcCt^t^)  -  90.00.  LOf,  0.0f,  0.00; 
head90[0] » 1.06 
head90[l]»0.0f; 
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head90(2]s0.0f; 

doqp  *  PFDOT_VEC3(head90,  ground->nonnal); 

pfMakeRotMat(m3.  (90.0f  -  pfAicCos(<lotp)),  0.0f.  l.Of,  O.Of); 
pfPieMultMat(m3,  m2): 

for  (sect  =  0:  sect<3:  sect++)  { 

pfSiiiCos(120.0f*sect+60.0,  &sh.  &ch); 

PFSET  VEC3(head(sectl(0].-sh.ch,0.00: 
pfXfonnPt3  (head(sectl[0],  head(sectl[Oh  m3); 
pfNormaJizeVec30iead[sect][0]); 
pfScaleVec3(head(sect][0],  3.0f.  head(sect][01); 
delta_heigiu[sect](0]  =  foot_daia{leg].foot_xyz(l]  - 
foot_data(leg]ibot_heig)u  + 
head[sectU0][2]  -  data[coum-M-l.point[2]; 

if  (delta_heighUsect][0]  <  deepest)  { 
deepest  =  delta_height[sect][0]: 
sector  s  sect: 
seg_ray  ss  count  - 1; 

) 

for  (int  nseg  =  0;  nseg<RAYS_PER_SECTOR  - 1:  nseg++)  { 
pfSmCos((angle*nseg>Kangle/2.0f>4<120.0f*sect).  8^,  &ch): 
ffSET  VEC3(haid{sect][nseg+ll.-sh,ch,0.0f); 
pfXfannPt3  (h^[sectl[nseg+l].  head[sect][nseg+l].  in3): 
pfNoimaiizeVec3(head[sectl[iiseg+l]): 

pfScaleVec3(h«9bd{sect][nseg-«-l],  FOOTPAD_RADIUS.  head(sect}[nseg+l]); 
dclBL.heigiitIsect](nseg+l]  *  foot_daiaOeg]ioot_xyzCll  - 
foot_dataOeg]ibot_height + 
head[sectj[nseg+l][2]  •  data[coiint44^].point[2]; 

if  (ddia_height[sect][iiseg+l]  <  deepest)  { 
deqiest »  delia_height[sect][iiseg4-l]; 
sector  s  sect; 
seg_ray  *  count  - 1; 

} 

} 

if  (deepest  <=  -2.5f)  { 

PFCOPY_VEC3(contact_points[sector],data(seg_iay].point); 
deepest  s  0.0f; 

} 

} 

pfM^PtsPlane(ground,  contact jx}ints[2],  contact_points[l],  contact_points[0]); 
pfNonnatizeVec3(ground->normal); 

if  (ground->n(»mal[2]  <  O.Of)  { 

pfN^ikePtsP!ane(ground,  contact_poinis[01,  contact_points[l],  contact_points[2]); 
pfNormalizeVec3(j^und->normal); 

if(pfSegIsectPIane(foot,  ground,  &foot_data(leg].foot_height)  =  PFIS_FALSE) 
print^“No  ground  intersection  2  for  leg  %iVn”,  leg); 

PFCOPY_VEC3(foot_data[leg]  .normal.  giound->normal); 
foot_data|leg].foot_xyz[l]  -=  (foot_data[leg].foot_hcight-  LINK4LENGTH); 
footIdat^eg}.giound_contact »  TRUE; 

}  //  end  orient_foot 


void  move_cainera_booin(pfDCS  *DCSbooin[3])  { 


pfDCSRot(DCSbo(»n[0],  (float)getvaluat«<OIALO),  O.Of.  O.Of): 
pfDCSRol(DCSbooin[li,  -(float)getvaIiiator(DIALl).O.Of,  0.00; 
pfDCSRot(DCSboom[21,  -(f1oat)getvaliiat^DIAL2),0.0f,  0.00; 

) 


//  Read  into  memory  materials  and  textures  used  in  the  simulation 
voidread.mateiialsO  ( 

if  (LoadGDL2C‘models/materials.gdl’’)  ss  NULL) 
fimntfCstdaT.’Unable  to  initialiye  material^”); 

if  (LoadGDL2(“models/showgdi.textuies.gdl’*)  =  NULL) 
fprintf<stdeir,”Unable  to  initialize  texturesNn’^; 

)  //  end  read_maierials 


//Read  in  the  terrain  model  and  assign  unique  characteristics 
pfGroup*  read.terrainO  ( 

pfGroup  *G_dirt,  *pond; 

Gjdiit  s  LoadGDL2C‘n)odels/test_floQr.gdl’0: 

pond  s  LoadGDL2Cinodels/)xind.gdl”); 

//  Set  up  the  intersection  marit  for  the  tnrain  toot  node 
pfNodeTravMask(G  dirtPFTRAV  ISECT, 

TERRAIN.MASK,  PFTRAV_SELRPFIRAV_DESCENDIPFTRAV_IS_CACHE.  PF_SED; 
pfNodeTravMask(pondJ*FTRAV  ISECT, 

WATER_MASK,  PFTRAV_SELF1PFIRAV_DESCENDIPFTRAV_IS_CACHE,  PF.SET); 
pf AddChild  (G.ditt,  pond); 
retum(G_ditt); 

}  //endread.terrain 
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II  ******m^m****m*******************************mm*m*****%*m*****tmm*****m*m* 

J/ FILENAME:  walk.C 

This  file  contains  the  functions  to  perform  a  simplistic  tripod  gait 


//PURPOSE: 

// 

//NOTE: 

//AUTHOR: 

//DATE: 

//COMMENT: 

//UPDATE: 

// 

/ 


This  progrm  is  written  in  C++  utilizing  Perfonner  1.0 
Wrus  Kiutiansen  and  John  Goetz 
20  February  1994 


//  External  access  to  two  functions:  (prototypes  in  “robot_globals.h”) 
// 

//  1 .  void  restart_robot(); 

//  Initializes  all  robot  parameters. 

//  placing  the  robot  at  the  origin  at  rest 
// 

//  2.  void  move_robot(fcs  joystick); 

//  Reads  the  system  clock  and  updates  robot  position. 

//  Joystick  is  accessed  for  an  “ordered  velocity”  at  the 
//  beginning  of  each  step.  (Joystick  pon  is  assumed 
//  to  have  b^n  successfully  opened  pritv  to  call) 

//  Robot  body  accelletaiion  is  non-infinite. 

// 


#include  <iostieam.h>  //for  error  messages 
#include  <stdio.h> 

#include  <stdlib.h>  //  for  exit  stmt 
#include  <math  Ji>  //  for  trig  functions  and  scp 

#include  <sys/times.h>  //  for  retrieving  system  time 
#include  <sysA)aiam.h> 

#include  "pf  h* 

//  Joystick  attached  to  HOTAS  Flight  Control  System  is 
//  us^  for  desired  velocity  input  for  the  robot. 

//  “fcs.H”  and  “fcs.C”,  written  by  Paul  Barham,  are  used 
//  fcff  access  to  the  device. 

#include  ‘*fcs.H”  //  for  joystick  access 


//  aqua  robot  deBnitions  and  globals  passed  to  draw  function 
#define  _COMMON_ 

#include  “robot_globaIs  Ji” 

//  LCX:AL  DECLARATIONS 

//joystick  stuff 

//  minimum  non-zero  value  recognized  for  joystick  input 
//  (smaller  values  are  zeroed) 

#defineJOY_MIN0.1 

//  Name  for  joystick  port 

//  gravy3&S  portname 

#define  JOY_SnCK_PORT  7dev/ttyd4’’ 

//  instanciate  fcs  object 

char  ♦pOT.name  =  JOY_STICK_PORT; 

fcs  joystick  (pm.name.  0, 0); 

//  end  of  joystick  stuff 
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II  for  angle  conversions  (radians  to/from  degrees) 

#definePI3.1416f 

#define  RADTODEG  57^958f 

#defu)e  DEGTORAD  0.0174533f 

#ddEine  MINIMUM(a,b)  ((a<b)?  a:b) 

#define  HYPT(a,b)  pfSqrt((a*a)+{b*b)) 

#define  LINK2SQR  (LINK2LENGTH  *  LINK2LENGTH) 
#define  LINK3SQR  (LINK3LENGTH  •  LINK3LENGTH) 


float  delta_tinie;  //  time  since  last  update 

float  scalar.speed;  //  for  robot  body 
float  joint_angles[18]; 


pfVec3  tpl_pos;  //  XYZ  center  of  legs  1,3.5  (tripod  1) 

pfVec3  tp2_pos;  //  XYZ  center  of  legs  2,4,6  (tripod  2) 

int  moving^len  .group;  //  IDs  stepping  tripod  (O=none) 
int  stepJnjwD^jress:  //  boolean 

int  reset;  //  boolean  to  flag  a  reset 

//Center  of  body 
pfVec3  robotjKsition; 

//  planned  end  of  step  positions 

pfVec3  nioving_group_goal4)os;  //  tripod  position 

pfVec3  body_goal  j)os;  //  robot  body  position 

pfVec3  actual.velocity; 

float  body_distance_this_stBpy/  scalar  distances  to  determine 
float  distance_to.jo;  //  pet  of  step  completed 

//  LOCAL  PROTOTYPES 

//  Detomines  which  tripod  will  take  the  next  stq). 

//  (Calculates  and  saves  goal  positions  for  body  and  stepping  tripod, 
void  plan_motion^fVec3  ordered); 

//  Increments  stepping  tripod  position  for  new  flame, 
void  move_tripod.jrou|Kintend_of_step); 


//  Calculates  leg  joint  angles  for  given 
//  robot  body  position  and  tripod  positions, 
void  calculi Joint_angIesO; 

void  move 4)erfotmer_DCS(pfDCS  *base,  pfDCS  *DCSlink[6][4]); 

//  Reads  joystick  of  an  PCS  object  and  returns  the  horizontal 
//  component  in  X  (left  -1  to  right  -t-l)  and  the  vertical  component 
//  in  Z  (ahead  -1  to  back  +1).  The  vector  sum  of  the  two  components 
//  is  normalized  if  greater  than  one  and  zeroed  if  less  than  JOYMIN. 
void  readJoystick(pfVec3  •ordered); 


46 


//  Establish  the  initial  posture  for  Aquarobot 

void  restart_robot(pfl>CS  *base.  pfl^S  •DCSlink[6][4])  { 

static  pfVec3  init_robot jwsidon; 

//  Place  robot  in  air  so  it  can  be  placed  on  torain  correctly. 
pfSetVec3(init_robot_position,  SO.Of,  ROBOT_HEIGirr,  O.Of): 

//joystick  setup 

//  Check  to  make  sure  the  PCS  was  found  on  the  desired  port 
//  and  that  the  PCS  is  communicating  coirectiy. 

if  (!joystick.existsO)  {  //  abort  program 
cerr  «  “Unable  to  communicate  with  joystick.”  «  endl: 
e3dt(0):  //  quit 


else  { //run  program 

//  Deaden  the  joystick  pitch  and  roll  so  user  can  rest 
//  hand  on  stidc  without  causing  movement 
joystick.deaden_pitch(O.OS); 
joystick.deaden_roll(0.05): 

//  Clear  joystick  input 

//  (need^  for  reset  so  robot  doesn’t  see  old  value) 
if  (joystick.new  data()) 

{ 

pystick.get_dataO; 
joysticltclear  dataO: 

} 

) 

//end  joystick  setup 

//  initialize  local  variables 
pfbiitClockO: 
scalar_speed  =  O.Of, 

moving  leg  group  =  0;  //  initially 

step_in_progress  =  0;  //  initially  false 

reset  =  1 ;  //  initially  true 

//  initialize  robot’s  foot  positions 

pfSetVec3f moving  group  goal  pos.  init_robot_position[0],  LINK4LENGTH, 
init_robot_position[2]); 

pfSetVec3(tpl_pos,  init_robot_position[0],  15.0f, 
init_rDbot_position[2]); 

p£SetVec3(tp2_pos,  init_robot_position[0],  15.0f, 
init_robot_position[2]); 

//  initialize  robot’s  body  position 
pfCopyVec3(body_goal_^,  init.robotjwsition); 
pfCopy  Vec3(robot_position.  init_robot_position); 

for  (int  leg  =  0:  leg<6;  leg++)  { 
foot_data[leg].ground_contact  =  TRUE; 
foot_data[legj.direction  =  POOT_UP; 
foot_data[leg].foot_xyz[l]  =  O.Of; 

1 
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//  initialize  robot’s  leg  joints 
calculate Joint_angl^); 

move_performer_DCS(base,  DCSlink); 

tpl  Dosfl]  =  LINK4LENGTH: 
tp2_pos[l] »  LINK4LENGTH: 

1 


//  Determine  location  of  center  of  body  based  on  joystick  input 

void  move_robot(pfDCS  *base,  pfDCS  ♦DCSlink(6][4])  { 

pfVec3  temp; 
pfVec3  ordered_veIocity; 

static  float  old.time; 

float  current_time  =  pfGetTimeO: 

int  end_of_step  =  0;  //  boolean  used  to  detect  end  of  step,  signal  to  put  feet  down. 

if  (reset) 
old.dme  »  O.Of; 

delta_time  =  current_time  -  old_time; 
old.dme  ~  cuirent.time; 
if  (delta.time  >  l.Of) 
ddta_times0.0Sf; 

if  (!step_in_progress)  { //  If  no  step  is  cunently  in  progress 

//  get  ordered  velocity  components 
readjoystickf&ordered.velocity); 

PFSCALE_VEC3(ordered_velocity,  MAX_SPEED,  otdered_velocity); 
PFCOPY_VEC3(actual_velocity,  ordered_vek)city); 

//  save  scalar  value 

scalar.speed  =  PFLENGTH_VEC3(ordered_velocity); 

//plan  the  step 

plan  motion(ordered_velocity); 

1 

//  calculate  distance  remaining  on  this  step 
reSUB_VEC3(temp,  body_goaljx)s,  robot_position); 
distance_to_go  =  PH£NGTH_VEC3(lemp); 


if  (distance_to_go  >=  delta_time  *  lO.Of)  /^jrevent  over-shoodng  goal 
ITSCALE_VEC3(actual_velocity,  (scalar_speed/distance_to_go),  temp); 

else 

end_of_step  =  1; 


//  update  robot’s  body  position 
reSCALE_VEC3(temp,  delta_time,  actual_velocity); 
PFADD_VEC3(r(^t_ix)sition,  robot_position,  temp); 


//  update  stepping  tripod  position 
if  (stepJnjMogress) 

move_tripod_group(end_of_step);  //  move  the  stepping  tripod  group 
calculate  Joint_angles();  //  update  all  eighteen  joints 
move_perfonner_DCS(base.  DCSlink);  //  Set  Perfonner  DCS’s 
reset  =  0; 

} 


II  Set  bodies  goal  position  based  on  joystick  input 
void  plan_motion(pfVec3  ordered)  { 
pfVec3  temp; 

//  detect  end  of  motion  condition 
if  (scalar.speed  =  O.Of)  //  stop  ordered 

//  and  was  previously  walking  (B)l_pos  not=  tp2_pos) 
if  (!PFEQUAL_VEC3(tpl  jws.  tp2j)os))  { 

//  plan  next  step  to  go  to  test  position 
switch  (moving_leg_group) 

//alternate  groups 
case(l): 

//  set  goals  for  rest  position 

pfCopyVec3(moving_group_goal_pos,  tpl_pos); 
pfCopyVec3(body_goal_pos.  tplrws); 
body_goal_pos[ll  =  ROBOT_H^HT; 

//switch  groups 
moving  _ieg  ^up  =  2; 

//enable  step 
step_in_progress  =  1; 
bre^ 

case  (2): 

//  set  goals  for  test  position 

pfCopyVec3(moving_group_goal_pos,  ^2_pos); 
pfCopy  Vec3(body_goal_pos,  tp2jx)s); 
body_goal_pos[l]  =ROBOT_HEIGHr; 

//switch  groups 
moving  leg  group  =  1; 

//enable  step 
stepJn_i»Dgress  =  1; 
break; 

)  //end  switch 
// set  half  speed 

scalar.spe^  =  0.5f  *  MAX_SPEED; 
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I 


else 

{ 

//  already  in  rest  position  (still  in  “stop  ordeied”  block) 
moving  leg  group  =  0; 

}//endif 


else  //  scalar.speed  (ordered  speed)  >  0 

//plan  next  step, 
switch  (moving  leg  group) 

{ 

//  alternate  groups 
case  (1): 

//  switch  groups 
moving  leg  group  =  2; 

//enable  step 
stq)_in_progiess  =  1; 

//  determine  goal  position  for  moving  leg  group 

pfSetVec3(moving_group_goalj)os.  tpl_pos{0]  +  STRIDE_TIME  ♦  orderediO],  LINK4LENGTH, 
tpl_pos[2]  +  STRnDE_TIME  *  ordaed[2]); 

//  detennine  goal  position  for  body 

pfSetVec3(body_goal_pos,  tpl_pos[0]  +  (STRIDE_TIME  *  orderedfO]  /  2.00, 

ROBOT_HEIGHT.  tpl jk)s[21  +  (STRIDE  miE  *  ordered[2]  /  2.00); 


break; 


// Y  positions  are  a  ccmstant 


case  (0): 
case  (2): 

//switch  groups 
moving  leg  group  =  1; 

// enable  stqi 
stq>_in_piogtess  =  1; 

//  determine  goal  position  for  moving  leg  group 

pfSetVec3(moving_group_goal_pos,  q)2_pos{01  +  STRIDE.TIME  *  ordeted[0],  LINK4LENGTH, 
tp2_pos[2]  +  STRn)E_T[ME  *  (Hxlered[2]); 

//  determine  goal  position  for  body 

pfSetVec3(body_goal_pos,  tp2_pos[0]  +  (STRIDE_TIME  *  ordered[0]  /  2.00, 

ROBOT_HEIGHT.  q)2_pos(2]  +  (STRIDE_TIME  *  ordered[2]  /2.00); 

break; 

)  //end  switch 

}  //  end  if  (scalar_speed  =  0) 

if  (step_injprogress)  //  new  st^  started 

{ 

//  set  length  of  step  for  pet  completion  calculation 

body_distance_this_step  =  PFDISTANCE_PT3(body_goal_pos,  robot_position); 

}//endif 

)  //  end  plan_motion 
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void  move_tripod_group(int  end_of_step)  { 

float  s,  c;  //  Places  for  sin  and  cos 
float  footjift; 
pfVec3  temp; 

static  float  last_tpl_height  =  0.0f,  last_tp2_height  =  O.Of; 

switch  (moving  leg  groupl 

case(l): 
if  (end_of_step) 

//  snap  position  to  end  of  step 
pfSetVec3(tpl_pos,  moving  group  gnal_pns(n], 

LINK4LENGTH,  moving  group  goal  pnsp]); 

//  reset  step_in_piogress 
step_in_progress  =  0; 

if(!foot_data(01.ground_contact)  { 
foot_data(0].ground_contact  =  TRUE: 

^  PFSET_VEC3(foot_data(0].normal,  O.Of,  O.ftf.  1.0f); 

if(!foot_data[2].ground_contact)  { 
foot_data[21.gTound  contact  =  TRUE; 

^  PFSET_VEC3(foot_data[2].nonnaI.  0.0f.  O.Of,  1.0f); 

if(!foot_data(4].ground_contact)  ( 
foot_data[4].ground_contact  =  TRUE; 

PFSET_VEC3(foot_daia[4].normal,  0.0f.  O.Of,  1.W); 

foot_data{0].direction  =  FOOTJUP; 
foot_data(2].diiection  »  FOOTiUP; 
fooc_data(4].direction  =  FOOT.UP; 

last_tpl_height  *  0.0f; 

) 

else 

{ 

if  (distance_to_go  <=  body_distance_this_step)  //  no  overshoot 
//  required  in  case  body  momentum  is  away 
//  ordered  direction  of  motion.  Delays  piclmg 
//  up  feet  for  next  step  until  stabilazadon. 

pfSinCos((RADTODEG  *  (PI  *  distance_to_go/body_distance_this_stM))),  &s,  &c); 
foot_lift  =  body_distance_this_stqj  *  s;  ~ 

PFSCALE_VEC3(temp,  (2.0f  *  delta_time),  actual_velocity); 
tpl_pos[l]  =  LINK4LENGTH  +  MINIMUM(MAX  JOOT_lJFT,foot_Uf^^ 

if  ((last_tpl_height  >  tpl_pos[l])  && 

(!foot_(i^[0].direction))  ( 

foot_data[0].diiection  =  FOOT_DOWN; 
foot_data[2].diiection  s  FOOT  DOWN; 
foot_data[4].direclion  =  FOOT~DOWN; 

} 

last_tpl_height  =  tpl_pos[l]; 

PFADD_VEC3(q)l_pos,  tpl_pos,  temp); 

)//endif 
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}//eiidif 

break; 

// end  case  (1) 

case  (2): 
if  (end  of_step) 

( 

//  snap  position  to  end  of  step 
pfSetVec3(tp2jx)s.  moving_group_ioaljx)s[0], 

LINK4LENGTH,  moving  group  goal  posf2n: 

//  reset  step_in_progress 
step_in_progress  =  0; 

if(!foot_data{l].gioiind_contact)  { 
foot_data[l].giound  contact  =  TRUE; 

PFSET_VEC3(foot  data(l].nonnal.0.0f.0.0f,  1.0f); 

} 

if(!foot_data(3].groiind_contact)  ( 
foot_data[31.giound_contact  =  TRUE; 

E*FSET_VEC5(foot_datal3].nonnal.  0.0f,  O.Of.  1.0f); 

} 

if(!foot_data(S].ground_contact)  ( 
foot_data[S].ground  contact  =  TRUE; 

PFSET_VEC3(foot_data(5].noiinai,  O.Of.  0.0f,  1.0f); 

foot_data(l].direction  =  FOOT_UP; 
foot_data[3].direction  =  FOOT_UP; 
foot_data(5].direction  »  FOOT.UP; 

last_q)2_height  *  0.0f; 

else 

{ 

if  (distance_to_go  <s  body.distance.this  jstep)  //  no  overshoot 

pfSinCos((RADTODEG  *  (PI  *  distance_to_go/body_distance_this_stq))),  &s,  &c); 
foot_lift  s  body_distance_this_stq)  *  s; 

H’SCALE_VEC3(temp,  (2.0f  *  delta_tinw),  actual.velocity); 
qj2_pos[l]  =  LINK4LENGTH  +  MIMMUM(MAX_FOOT_LIFr4bot_lift); 

if  ((Iast_tp2_height  >  tp2_pos[l])  && 

(!foot_daia(l].direction))  ( 

foot_dab^l].direction  =  FOOT_DOWN; 
foot_data[3].direction  =  FOOT JX)WN; 
foot_data(5].direction  =  FOOT_DOWN; 

} 

last_tp2_hdght  s  tp2_pos[l]; 

PFADD  VEC3(q)2_pos,  q)2_pos,  temp); 

}//endif 

)//endif 

break; 

//end  case  (2) 

}//  end  switch 
)//  end  move_tcipod_gioup 

void  calculate  Joint.anglesQ  { 

pfVec3  jointl  j)os;  //  XYZ  coordinates 


52 


p£Vec3  jomt2_pos;  //  “ 
pfVec3  temp; 

float  ml.  ml  r,  dy.  dxz.  rsqr. 

float  s.c;  // Holds  sin/cos  ^ues 

register  int  leg;  //  loop  variable  (0  =  leg  1) 

f(»<leg  =  0;  leg  <  6;  leg++)  { 

//determine  joint  1  position 

PFSET_VEC3(temp.  offset_factor0eg*2]*LINK0LENGm 
0.0f.  offeet_factOT(leg*2+l]*LINKQLENGTH); 
PFADD_VEC3(jointl_pos.  tobot_position,  temp); 


//  determine  foot  position 
switch  (leg)  { , 

case  (0):  case  (2):  case  (4):  //  legs  1,3&S  on  tiqxxl  1 

if  ((!foot_data[leg].ground_contact)  II 
((!foot_data(leg].direction)  && 

(q>l_pos[l]  >=  foot_data(leglioot_xyz[l])))  { 

PFSET_VEC3(tcmp.  (offset  factor[l^*2]*FOOT  RADIUS). 
0.0f,  (ofiEset_factorOcg*2+l]*FOOT_RADnjS)); 

FFADD_VEC3(foot_data(leg]ioot_xyz,  tpl_pos,  temp); 
if  (step_in_piogress) 
foot_data[leg].ground_contact  =  FALSE; 

break; 

case  (1);  case  (3);  case  (S);  //  legs  2,4&6  on  trqxxl  2 

if  ((!footjdaiaOeg].|roiind_contact)  II 
((!foot_dataDeg].ffliection)  Sc& 

(tp2_pos[l]  >=  foot_dataQ^ioot_xyz[l])))  { 

PFSET_VEC3(teiiip,  ((rf&et_factocO^*2]*FOOT  RADIUS), 
0.0f,  (offset_factor0cg*2+ll*FCX)T_RADIUS)); 

PFADD_VEC3(foot_data0eg]ibot_xyz,  tp2_pos,  temp); 
if  (step_in_piogress) 
foot_data[leg].gtound_contact  =  FALSE; 

break; 

)  //end switch 


//  calculate  kwnt  1  angle  using  slopes 
//slopeof  line  from  body  center  to  joint  1 
ml  =  (jointl_pos[2]  -  Tobot_position[2])  //dZ 
/(jointl_j)os[0]  -  robot_position[01);  //  dX 
//sh^  of  line  mm  joint  1  to  posidtmdii^y  above  foot 
m2=  (foot_dataDeg].foot_xyz[2]  •jointl_po^2])  //dZ 
/(foot_data(leg]  Jbot_xyz[0]  -  jointl_pos[0]);  //  dX 
joint_angles[3*leg]  =  pfArcTan2((m2  -  ml),  (1.0f + (ml  *  m2))); 

//  determine  joint  2  position 

pfSinCos(RADTODEG  *  ((PI*leg/3.00  +  (DEGTORAD  •  joint_angles[3*leg])).  &s.  &c); 
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PFSET_VEC3(temp.  UNKILENGTH  *  c.  0.0f.  UNKILENGTH  *  s); 
PFADD_VEC3(joint2_pos,  jointl  jxb,  temp): 

//  detennine  length  of 

//  the  thiid  side  of  triangle  (joint  2.  joint  3.  foot). 

dy  =  jointl_pos(l]  -  foot_d^leg]ibot_xyz[l];  //  Y  coordinate 

dxz  *  HYPT((joint2  j)os[0]  -  foot_data(leg]ioot_xyz[0]),  //  X  coordinate 
(joint2  dos[2]  -  foot_data0e^.foot_xyz[2]))‘7/  Z  coordinate 
r  a  HYPT(dy,  dxz);  //length  of  third  side 

//  need  squares  of  all  three  sides  for  “law  of  cosines” 
tsqr  a  r  *  r, 

//  calculate  joint2  angle  using  law  of  cosines 
joint_angles[3*teg-«-r]  a 

p£^Cos((IJNi^QR  +  rsqr  •  LINK3SQR)  //  A3  (angle  opposite 
/(2.0f*LINK2LENGTH*r))  //  LINK3LENGTH) 

•  pfAicSin(dy/r);  //-phi 

//  calculate  joints  angle  using  law  of  cosines 
joint_angies(3*Ieg+2]  =  //  Ar  (angle  (^>posite  r) 

pfAicCos((UNK2SQR  +  LINK3SQR  -  rsqr) 

/(2.0f  *  LINK2LENGTH  *  LINK3LENGTH)); 

)  // end  fw  loop 


}  //  end  calculate Joint_angles 


54 


//  Update  DOS’s  to  display  new  position 

void  move_perfonner_DCS(pfDCS  *base,  pfDCS  ♦DCSlinkf6][4])  { 

static  pfMatrix  ml; 

//  Move  robots  center  of  body  (convet  to  robodcs  cotHtlinate  system) 
pfDCSTrans(base.  tobot_position(01,  robot_position[2].  -robot_position[l]); 


for  (int  leg  =  0:  leg  <  6;  Ieg++)  { 

pfDCSRot(DCSlink[leg][0],  joint_angles(3*leg].  0.0f,  0.00: 
pfDCSRot(DCSlinlc[legj[li.  joint_angles[3*leg-i-l].  O.Of,  0.00; 
pfDCSRot(DCSlink[leg][2j,  ISO.Oif  +  joim_angles[3*leg+2],  0.0f.  0.00; 

//  Translate  foot  into  correct  position  (worid  coordinates) 

pfMakeTransMat(foot_data[leg]ioot_inat,foot_data{leg].foot_xyz[0], 

fooi_datalleg].foot_xyz[2].-foot_data(leg]ioot_xyz[l]); 

U  If  foot  is  in  the  air.  keq)  it  level  and  have  it  rotate  with  shoulder 
if  (!foot_data(leg].ground_contact)  ( 
pfMakeRotl^ml.  joint_angles[3*leg},  O.Of,  OM,  1.00; 
pfPostMultMat(ml,  foot_data(leg].foot  mat); 
^pfDCSMatr«(DCSlink(leg][3].ml); 

}  //end  for  statement 
}  //  end  move _pcrformer_DCS 


I  I  Check  the  joy^k  for  response 
void  readJoystick(pfVec3  ^ordered)  { 

pfVec3  sdck.ditection; 

if  (joystick.new_data())  { 

//read  joystick  data 
joystick.get_data(); 

pfSetVec3(stick_direction.  joystick  JoUQ,  O.Of,  joy^ck.pitch0); 
pfNormalizeVec3(stick_diiwaon); 

//  mark  current  data  as  used 
joystick.clear_dataO; 

if  (pfLengthVec3(stick_direction)  <  JOY_MIN) 
pfSetVec3(stick_<hrection,  joystick  joUQ.  O.Of.  joystictpitchO): 
)  //end if 

//  write  return  values 

PFCOPY_VEC3(*ordered,  stick_direction); 

)  //  end  read  Joystick 
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APPENDIX  B:  SIMULATION  SUPPORT  CODE 


// 

//  iobot_globals.h 

II 

H  written  by  Wnis  Kristiansen  and  John  Goetz 

// 

//  Global  derinidons.  variables  and  animadon  function  prototypes 
//  for  aquarobot,  a  six  legged  underwater  walking  robot. 

// 

//  Aquarobot’s  posidonal  data  are  calculated  in  fimcdons 
//  and  passed  through  variables  declared  in  this  header  to 
//  external  robot  drawing  funcdon  written  by  John  Goetz. 

// 

//  Funcdon  definidons  ate  in  “waULC”. 

It 


tifiidef  _ROBOT_GLOBALS_H 
#define  _ROBOT_GLOBALS_H 

#include“pf.h*’ 

#ifdef_COMMON_ 

»define£XlERN 

^telsc 

#define  EXTERN  extern 
#endif 

typedef  struct  { 

pfVec3  foot_xyz; 
pfNfattix  foot.mat; 
pfVec3  normal: 
int  ground.contact; 
intdiiecdon; 
float  foot.height; 

)  FOOT.DATA; 

EXTERN 

FOOT.DATA  foot_datal6]; 

//  Defines  fw  foot  diiecdon 
#defineFOOT  UPO 
#define  FOOT.DOWN  1 

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiim 

H  n 

I  I  all  posidontd  information  is  based  on  a  left  handed  // 

//  XTL  coordinate  system:  +X  »  right,  -t-Y  =  up.  4-Z  =  toward  // 
//  viewer  (out  from  screen).  (SCA1£  1.0  s  i  centimeter)  // 

//  // 

lllllllllllllllllllllllllllllllllim 


// 

//DEFINITIONS 

// 

//  Any  of  these  may  be  adjusted:  however,  care  must  be  taken 
//  not  to  exceed  physical  limitations.  For  example,  the  product 
//  of  MAX.Sre^  and  STRIDE_TIME  should  not  exceed  SO  for  the 
//  current  dimentional  limitations  of  the  robot.  i.e.  it  can’t 
//  take  2  second  steps,  going  400cm/sec  because  its  legs  can’t 
//  reach  far  enough  to  move  the  body  8  meters  per  step... 

11 

I  I  maximum  robot  speed  in  cm/sec 
#defineMAX_SPEED  33.33f  //25.0f 

//  radius  of  feet  positions  in  cm 
#defmeFOOT_RADIUS  109.0f 

//  max  height  foot  lifted  during  step 
#defineMAX_FOOT_LIFT20.0f  //IS.Of 

//  time,  in  seconds,  for  one  step 
#define  STRIDE.TIME  1.5f  //2.0f 

//  The  floor  for  the  robot  to  walk  on  is  the  plane 
//  described  by  Y  =  0.0. 

#define  FLOOR_LEVEL  0.0f 


Robot  height » 


height  of  joint  1  above  floor  in  cm 


#defineROBOT_HEIGIiri02.0f  //910f 

// 

//  ROBOT  DIMENSIONS 

II 


LINKLENGTHS  in  cm 


I*  link  lengths  *1 
#define  LINKOLENGTH  37.5f 
#define  LINKILENGTH  20.0f 
#d(^  LlNK2LENG'm  S2.0f 
#define  LINK3LENGTH  102.0f 
#define  LINK4LENGTH  3.0f 
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// 

// Offset  matrix. 

11 

I  I  For  position  of  first  joint  of  a  leg.  multiply  X  and  Z 
//  compoimts  by  bodyiadius  and  add  to  body  position; 

//  Fot  position  ttf  a  foot,  multiidy  X  and  Z  components 

//  by  FOOT.RADIUS  and  add  to  apinopriate  tripod  petition. 
//Leg  1  is  on -t-X  axis,  and  legs  2  through  6  are 

II  at  ^  degree  intervals. 

const  float  offset.factoif  12] »  { 

//  Xcomponem  Zcomponent 
//  leg  1  cos(0)  sin(0) 

1.0.  0.0. 

//  leg  2  €05(60)  sin(60) 

0.5.  0.866. 

//leg  3  cas(120)  sin(120) 

-0.5.  0.866. 

//leg 4  cos(180)  sin(180) 

-1.0.  0.0. 

//leg  5  cos(240)  sin(240) 

-0.5.  -0.866. 

//leg 6  cos(300)  sin(300) 

0.5.  -0.866}; 

//  aqua  robot’s  body  position.  (X.  Y.  Z  coordinaies) 

// 

//  Since  orientation  is  constant,  this  is  sufficient 
//  to  totally  describe  the  postition  of  the  body. 

//  aqua  robot’s  leg  joint  angles. 

//  Hiree  joint  angles  are  defined  for  each  leg. 

// The  joints  and  their  0.  and  -  angles  are 
//  pictcHtially  described  as  follows: 

If 

// 


joint  1  joint  2  joint  3 


//  current  angles  for  all  joints 
//leg  1,  joint  1,2,3. 

//leg  2,  joint  1,2, 3, ... 

//leg  6,  joint  1,2,3, 


//  FUNCTION  PROTOTYPES 
// 

//  Initializes  all  robot  global  variables,  positioning 
//  the  robot  at  die  origin  in  the  rest  position. 
voidrestart_iobot(pfIX^S  *base,  pflX^S  *DCSlink(61[4]); 

//  Reads  system  clock  and  updates  robot  position 
//aiul  joint  angles. 

//  Reads  fcs  object,  joystick  pitch  and  roll  components. 

//  for  motion  orders.  FCS  object  must  be  valid* 

//  Returns  robot  to  rest  position,  body  and  tripod 
//  centers  having  equal  X  and  Z  coordinates,  when 
//  ordered  velocity  is  0. 

void  move_robot(pflX}S  ‘base,  pfDCS  •DCSlink[6][4]): 


#endif  // _ROBOT_CLOBALS_H 
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jj **mm**mm*m****m*m********m*****m*********mm*mm***m***m******************** 

//FILENAME:  SGIwindowcam.C 

//  PURPOSE:  This  program  contains  the  functions  for  queing  devices  and 
//  checking  the  events  queue  for  mouse  and  spaceball  events.  It 
//  also  contains  the  functions  for  controling  the  camera  and  focal 

//  point 
// 

//  NOTE:  This  is  and  IRIS  3D  program  written  in  C-m- 
// AUTHOR:  John  Goetz, 

//DATE:  15  January  1994 
//CXJMMENT: 

//UPDATE: 

j/******m*m****m**********************m******m*****^*m**^****»m^**^********* 

#inciude  <gi/gl  Ji> 

#include  <stdUb.h> 

#include  <gl/device.h> 

#include  <gl/spi^ball.h> 

#include  “SGIwindowcam.H” 

#include  “pf.h” 

#define  RESET  14  //  pop  up  menu  item 
#defineEXIT  15  // pop  up  menu  item 

#dcfineRADTODEG  57.2957795  If 

#define  SBRATIO  0.0004f  //  spaceball  rotational  scale  factor 

#define  SBTRATIO  0.008f  // spaceball  translational  scale  factor 

#definePIE  3.141592654f 

#definePIEOVER2  1.570796327f 

#defineTWOPIE  6.28318S308f 

long  topmenu;  //pop  up  menu  hook 


^m^,mi$mm***mm**m*m********************0*»»**mi 

r  Function  initialize  */ 

void  initializeO  ( 


//  Que  the  devices  and  keys  to  be  used 
qdevice(REDRAW);  //  queue  the  redraw  device 
qdevice(MENUBUTTON);  // queue  the  menubutton 
qdevice(LEFTMOUSE);  //  Initialize  Mouse  Buttons  to  be  Queued 

qdevice(SBTX);  //  SpaceBall  Translate  in  X 
qdevice(SBTY); 
qdevicefSBTZ); 

qdevice(SBRX);  //  SpaceBall  Rotate  about  X 

qdevice(SBRY); 

qdevicefSBRZ); 

qdevice(SBPERIOD);  //  SpaceBall  time  (telta 
qdevice^SCKEY);  //  Exits  program 
qdevice^lKEY);  //  Toggles  statistical  information 
qdevice^KEY);  //Toggles  fog 

//  Set  the  limits  for  the  dials  to  be  used 
setvaluator  (DIALO,  0,  -10000, 10000); 
setvaluator  (DIALl,  0, 40, 50); 
setvaluator  0IAL2, 0,  -90, 90); 
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//  Set  dead  band  for  the  dials  to  be  used 
noise(DIALO.  2): 
noise(DIALl,  2); 
noise(DIAL2. 2); 

//  Create  the  pop~up  menus  to  reset  simulation  and  exit  program 
makethemenusO; 

}  //  end  inidalizeO 


l^*^r***m******************’>‘********m***********************mm*****^t****<ti**i 

I*  Function  Make_the_Menus  */ 


void  makethemenusO  { 


//  build  the  top  level  pop-up  menu 
topmenu  =  defpup(“Reset  %xl4l  Exit  %xl5”): 

} 


/*  Function  Check_Que  •/ 

y*«*4i**««**«««<ti«««*«**«*««4<«*«««4i*4i***4i«4i«*4i*4i*«*4i«**««******«**«*<|i**«*««*i»y 

void  Check_Que(SharedData  *data)  { 


long  device: 

long  hititem:  // variable  holding  hit  name 
short  value:  //  value  returned  from  the  event  queue 
short  sbvals[7];  //  array  to  hold  spaceball  values 
short  kbvals[7]:  //  array  to  hold  keyboard  values 

//  do  we  have  something  on  the  event  queue? 
while  (qtestO) 

device  =  qtead(&value): 
switch  (device) 

( 

//  Redraw  window  after  resizing,  not  needed  for  a  fixed  windowsize 
case  REDRAW: 
reshapeviewportO; 
break; 

case  MENUBUTTON:  //  Menu  selections 
if  (value  *=  1) 

{ 

I*  which  popup  selection  do  we  want?  */ 
hititem  s:  dopup(topmenu); 

switch  (hititem)  ( 
case  FESET: 
data->resetFlag  =  1; 
break; 


case  EXIT: 
data->exitFlag  =  1; 
break; 

} 


}  //  end  if  for  MENUBUTTON 

brkk; 


i 

( 
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case  (SBPERIOD): 
case  (SBTX): 
case  (SBTY): 
case  (SBTZ): 
case  (SBRX); 
case  (SBRY): 
case  (SBRZ): 

sbv^s[device-SBTX]  =  value: 
if  (device  =  SBRZ) 
calculate_view(sbvals.  &data->view); 
break; 

/*  ESC-key  signals  end  of  simulation  */ 
caseESCKEY: 
data->exitFlag  =  1; 
break; 

/*  Fl-key  toggles  channel-proEle  display  */ 
caseFlKEY: 
if  (value  —  1) 

data->pfStats  =  !data->pfStats: 
break; 

/*  F2-key  toggles  underwater  environment  */ 
caseF2KEY: 
if  (value  —  1) 
data->pfFog  =  !data->pfFog; 
break; 

default: 

break; 

}  //end  switch 
)// end  while  qtest 
qresetO; 

)  //  end  of  Check_Que 
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/************m*****m**********<¥m*********m**m*m**m**mm****m*********m******f 
f*  Function  calculate. view  */ 

/********m***m****t******m**m*m*******m****<nm*m*****mm***************m******f 

void  calculate_view(shon  valued,  pfCooid  *view)  { 
float  sh,  ch.  sp,  cp,  sr,  cr. 


//  calculate  (pitch) 

if  (view->hpr[l]  +  (valuefS]  *  SBRATIO)  >  90.00 
view->hpr[l]  =  90,0f; 

else 

if  (view->hpr[l]  +  (value[3]  *  SBRATIO)  <  -  90.00 
view->hpitl]  =  -90.0f; 

else 

view->hpr[l]  +=  value[3]  ♦  SBRATIO; 

//  calculate  (roll) 

if  (view->hpr(2]  +  (value[5]  *  SBRATIO)  >  90.00 
view->hpr[2]  =  90.0f; 

else 

if  (view->hpr(2]  +  (value(5]  *  SBRATIO)  <  -  90.00 
view->hint2]  =  -90.0f; 

else 

view->hpr(2]  +«  value[51  *  SBRATIO; 

//  calculate  (heading) 

if  (view->hpr(0]  +  value[4]  •  SBRATIO  >  360.00 
vTew->h^0]  =  (view->hprf0]  +  value[4]  •  SBRATIO)  -  360.0f; 

else 

if  (view->hprt0]  +  value[4]  *  SBRATIO  <  -  360.00 
view->h^0]  =  (view->hpr[0]  +  value[4]  *  SBRATTO)  +  360.0f; 

else 

view->hpr[0]  +=  value[4]  ♦  SBRATTO; 

pfSinCos(view->hpr[0],  &sh,  &ch); 
pfSinCos(view->hpr[l],  &sp,  &cp); 
pfSinCos(view->hpr[2].  &w,  &cr); 


//  Calculate  Performer  Y-axis  position 

if  (view->xyz[l]  +  (value(2]*ch  +  value[0]*sh)  *  SBTRATTO  <  -3000.00 
view->xyz[l]  =  -3000.0f; 


else 

if  (view->xyz[l]  +  (value[2]*ch  +  value[0]*sh)  *  SBTRATTO  >  3000.00 
view->xyzfl]  =  3000.0f; 

else 

vicw->xyz(l]  +=  (value[2]*ch  +  value[0]*sh)  •  SBTRATTO; 
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//  Calculate  Performer  Z-axis  position 


if  (view->xyz[2]  +  value[l]  ♦  SBTRATIO  <  5.00 
view->xy2[2J  =  5.0f: 

else 

if  (view->xyz[2]  +  value!  1]  *  SBTRATIO  >  1000.00 
view->xyz[2]  =  lOOO.Of; 

else 

view->xyz[2]  +=  valuetl]  *  SBTRATIO; 


//  Calculate  Perfonner  X-axis  position 

if  (view->xyz(0]  -  (value(2]*sh  -  value(0]*ch)  *  SBTRATIO  <  -3000.00 
view->xyz(0]  =  -3000.00 


else 

if  (view->xyz[0]  -  (value[2]*sh  -  value[0]*ch)  •  SBTRATIO  >  3000.00 
view->xyz[0]  =  3000.0f; 

else 

view->xyz[0]  -=  (value[2]*sh  -  value[0]*ch)  *  SBTRATIO; 

}  //  end  calculate.viewQ 


//  FILENAME:  loadGDL.h 


//  PURPOSE:  This  program  contains  the  liincdons  prototype  for  loading  a  file 
//NOTE: 

//AUTHOR:  John  Goetz, 

//DATE:  15  January  1994 
//COMMENT: 

//UPDATE: 


#ifndef  _LOADGDL_H_ 
fdefine  _LOADGDL_H_ 

#include  “pf.h” 

pfGroup'*  LoadGDL2(char*  filename); 
#endif 
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APPENDIX  C:  LOADING  NPSGDL2  FILES  INTO 

PERFORMER 


1.  PURPOSE 

The  purpose  of  this  loader  is  to  enable  the  use  of  the  extensive  model  library  that  has 
been  created  using  Object  File  Format  (OFF),  NPS  Graphics  Description  Language 
(NPSGDL)  or  NPS  Graphics  Description  Language  n  (NPSGDL2)  in  Performer 
applications.  These  three  formats  differ  slightly  and  some  text  editing  of  the  model 
description  is  required  to  convert  OFF  and  NPSGDL  files  into  the  NPSGDL2  format  For 
a  complete  description  of  NPSGDL  see  [Ref.  15] 

2.  GENERAL  DESCRIPTION 

The  loader  reads  a  NPSGDL2  file  and  stores  all  similar  geometry  with  the  same  state 
and  same  pnedraw  callback  in  a  pfGeode.  .State  refers  to  the  color,  material,  texture  or 
texture  environment  The  predraw  callback  is  discussed  on  page  69.  When  the  state 
changes,  the  current  geoset  along  with  its  state  information  (geostate)  is  attached  to  the 
current  pfGeode.  A  new  geoset  and  geostate  is  then  created.  If  the  state  is  changed 
redundantly  (red,  white,  red,  white)  many  times,  an  excess  number  of  pfGeosets  will  be 
created  and  will  increase  the  traversal  time  for  the  scene.  In  order  to  alleviate  this  problem 
it  is  useful  to  group  all  polygons  with  similar  characteristics  (state)  togetiiCT  in  the  model 
fUe 

After  the  entire  model  file  has  been  read  in,  all  the  pfGeodes  which  have  been  created 
are  attached  to  a  pfGroup.  A  pointer  to  the  pfGroup  is  returned  to  the  main  application  for 
the  user  to  attach  to  the  scene.  The  following  sample  code  shows  how  to  load  a  file: 

#include  “loadGDL.h” 

#include  “pf.h” 

pfGroup  *G_dirt; 

G_dirt  =  LoadGDL2(“models/test_floor.gdr’); 
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3.  PRIMUIVES 

Performer  only  allows  for  a  few  well  defined  primitives.  These  are  points,  lines, 

linestrips,  tris  (triangles),  quads  (quadrilaterals)  and  tristrips^  GDL  allows  lines,  Tmeshes 
(triangle  mesh),  Qstrips  (similar  to  tristrips  except  components  are  quadrilaterals)  and 
polygons  which  may  have  any  number  of  sides  (sides  >  2). 

NPSGDL  Tmeshes  convert  easily  to  Performer  tristrips.  Qstrips  and  lines  were  ignored 
since  these  features  did  not  seem  to  be  used  very  often.  Polygons  on  the  other  hand  are  used 
extensively  and  the  limited  Performer  primitives  must  be  made  to  handle  any  polygon.  For 
this  reason  all  polygons  are  converted  to  Performer  tristrips.  This  is  accomplished  by  the 
loader  and  is  transparent  to  the  user. 


Figure  Cl:  CoPiverting  a  polygon  to  a  trimesh 

Figure  Cl  depicts  a  typical  6  sided  polygon  and  how  the  loader  breaks  it  down  into  a 
trimesh.  The  dashed  line  depicts  the  vertex  path  traversed  by  the  loader  (1, 2,  N,  3,  N-1, 4, 
N-2),  and  the  solid  lines  depict  the  sides  generated  by  the  tristiip  algorithm.  The  loader  can 
convert  any  convex  N-sided  polygon 

It  is  not  apparent,  but  there  is  a  difference  between  trimeshes  and  polygons  converted 
into  trimeshes.  It  is  in  the  way  they  are  indexed.  Referring  to  Hgure  Cl,  the  vertices  of  a 


1.  A  tiistrip  is  a  collection  of  three  sided  polygons  specified '  mence  of  the  three  most  recrat 

vertices.  Also  referred  to  as  triangle  mesh 
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trimesh  would  be  entered  in  the  order  (1^,6,3.5,4).  The  index  list  (traversal  order)  would 
be  NULL,  meaning  the  vertices  will  be  traversed  in  the  order  they  were  entered.  The 
vertices  for  a  polygon  would  be  entered  in  the  order  (1,2, 3, 4,5,6)  and  the  index  list  would 
be  (1,2,6, 3,5,4). 

The  loader  can  be  changed  to  handle  3  and  4  sided  polygons  more  efficiently,  but  this 
would  require  editing  the  model  flies  and  grouping  similar  polygons  together  to  minimize 
changes  in  the  primitive  type.  Redundant  changes  will  create  an  excess  number  of  geosets 
which  will  slow  traversal  time. 

4.  COORDINATE  SYSTEM 

Performer  utilizes  an  orthogonal  coordinate  system  defined  with  the  Y  axis  to  the  right, 
Z  axis  up,  and  the  X  axis  out  of  the  screen.  This  differs  from  IRlS's  GL  (Graphics  Library) 
coordinate  system;  utilized  by  GDL2;  which  has  the  X  axis  to  the  right,  Y  axis  up,  and  the 
Z  axis  out  of  the  screen.  In  order  for  models  stored  using  GDL  to  {q>pear  correctly  when 
rendered  using  Performer,  the  loader  changes  the  order  of  dre  vertices  from  XYZ  in  GDL 
to  YZX  in  performer. 

5.  MATRIX  TRANSFORMATIONS 

The  NPSGDL2  commands  for  manipulating  the  model  view  stack  (scale,  rotate, 
translate,  pushmatrix,  popmatn  o^otmatrix)  are  used  by  the  loader  to  transform  vertices 
to  their  desired  location.  Polygon  and/or  vertex  normals  are  also  transformed,  but  only  by 
the  rotation  matrix. 


Level  0 

SCALE 

ROTATE 

TRANSLATE 

Level  1 

SCALE 

ROTATE 

TRANSLATE 

Level  2 

SCALE  1 

ROTATE 

TRANSLATE 

• 

Level  9 

SCALE 

ROTATE 

TRANSLATE 

Figure  C2:  GDL  Loader  Matrix  Array 
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The  loader  has  an  array  of  ten  sets  of  matrices.  Each  matrix  set  consists  of  three  4x4 
matrices,  one  for  scale,  rotate  and  translate  (see  Hguie  C2).  When  any  or  all  of  the  matrices 

are  defined,  they  are  multiplied  together  in  the  order  S  x  R  x  T  and  the  resultant  matrix  is 
placed  at  the  top  of  the  array  (Level  0).  All  vertices  that  follow  are  transformed  by  the  top 
level  matrix  prior  to  being  saved  in  the  pfGeoset  When  a  pushmatrix  is  encountered  the 
array  is  incremented.  All  three  matrices  of  the  new  level  are  loaded  with  the  identity  matrix 
and  they  are  ready  for  assignment  A  popmatrix  decrements  the  array  and  the  previous 
matrix  is  returned.  The  loader  will  not  allow  a  user  to  push  more  than  10  matrices  nor  pop 
more  matrices  than  were  pushed. 

a.  LOADING  A  MATRIX 

The  rotation  matrix  only  allows  for  single  axis  rotations.  If  multiple  rotations  are 
desired  then  the  loadmatrix  command  can  be  used  to  enter  a  4  X  4  homogeneous 
transformation  matrix.  The  matrix  is  entered  in  column  vector  format  (translations  in  the 
last  row);  common  in  graphics;  not  row  vector  format  (translations  in  the  last  column); 
which  is  common  in  robotics. 

This  matrix  is  physically  stored  in  the  rotate  matrix  position  of  the  current  matrix 
level.  In  order  to  correct  for  the  coordinate  system  differences  between  GDL2  and 
Performer,  the  loader  transforms  the  matrix  to  correspond  to  the  Performer  coordinate 
system. 

6.  RENDERING  ATTRIBUTES 

Specifying  the  appearance  of  priiititives  may  be  accomplished  using  setcolor, 
setmaterial  or  settexture.  If  textures  are  used,  then  a  texture  environment  must  also  be 
specified.  Texture  coordinates  may  be  assigned  in  the  polygon  description  of  the  model  or 
automatically  generated  by  specifying  a  texture  generating  algorithm. 
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a.  TEXTURE  COORDINATE  GENERATION 

The  GL  graphics  commands  for  automatically  generating  texture  (texgoi) 
coordinates  have  been  placed  in  a  predraw  callback  for  pfGeodes.  Each  time  the  texgen 
plane  equation  is  changed,  a  new  geode  is  created  and  attached  to  the  tree  with  a  new 
callback.  For  a  complete  description  of  GL’s  texgen  fimction,  see  [Ref.  16]. 

7.  COMMENTS 

Comments  are  allowed  in  the  model  files  in  either  C  notation  I*  */  or  C-m-  notation  //. 

8.  FUTURE  WORK 

The  following  GDL2  commands  are  not  recognizable  by  the  loader: 

•  deflight,  setlight 

•  deflmodel,  setlmodel 

•  decals 

•  defline 

•  defqstrip 

•  loadunit 

The  following  GDL2  commands  are  recognizable  by  the  loader,  but  have  not  been 
implemented  at  this  time: 

•  bounds 

•  origin 

9.  TESTING 

The  loader  has  been  tested  successfully  on  several  difierent  GDL2  files.  However,  this 
does  not  mean  it  has  survived  rigorous  and  thorough  testing.  If  anyone  using  this  loader 
should  have  difficulties,  please  send  email  to  goetzjt@scs.usna.navy.mil  with  a  description 
of  the  problem  and  it  will  be  investigated. 

10.  SOURCE  CODE  AND  LIBRARY 

The  source  code  for  the  loader  is  located  in  /n/elsie/work3/goetzjr/loadgdl/  and  the 
library  is  libpfgdl.a.  The  library  utilizes  a  pointer  repository  to  reserve  memory  for 
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instantiating  template  objects.  In  order  for  this  repository  to  be  visible  by  an  application, 
the  entire  path  name  of  the  repository  must  be  specified  in  the  makefile.  An  example  of  this 
is: 

C++FLAGS  =  $(INCLUDES)  pte.C  -ptr/n/elsie/work3/goeizjr/loadgdl/ptrepository 
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